Ruby on Rails: Russian Translation and Pluralization

2018-04-12T00:00:00+00:00

[Photo by Matthew Henry of Burst](https://burst.shopify.com/photos/woman-codes)

Russian is Hard

Translation to Russian is tricky, and what’s even more tricky is coding logic to handle localization and pluralization of Russian (especially when you can’t read it). Here, I’ll explain some of the complexities and approaches I used for localization of a Ruby on Rails application.

Pluralization

In general, Rails claims to have good localization and pluralization support, but I found that the support for handling more complex translations required customization. The first thing to note is that pluralization in Russian is not quite as simple as it is in English.

English

In English, we are familiar with pluralization of regular nouns to be appending an ‘s’ to the end of the noun (except for those nouns ending in ‘y’ and ‘o’). Pluralization is irregular in some cases, e.g. “octopus” becomes “octopi”, and Rails can handle some of these special cases for English but may not necessarily understand rules for other languages. See:

pry(main)> pluralize 1, 'user'
=> "1 user"
pry(main)> pluralize 2, 'user'
=> "2 users"
pry(main)> pluralize 1, 'octopus'
=> "1 octopus"
pry(main)> pluralize 2, 'octopus'
=> "2 octopi"

Wikipedia has a thorough explanation of English plurals here for anyone interested.

Russian

Russian pluralization is more complex. In the most simplified terms (from my understanding), the mapping can boil down to:

where count is zero, word has one ending
where count is one, word has another ending
where count is 2–4, 22–24, 32–34, word has yet another ending
where count is 5–20, 25–30, 35–40, …: word has yet another ending

To accomplish this translation and pluralization in Rails, I implemented the following mapping found here:

{:ru =>  
  { :i18n =>  
    { :plural =>  
      { :keys => [:zero, :one, :few, :other],
        :rule => lambda { |n| 
          if n == 0
            :zero
          elsif
            ( ( n % 10 ) == 1 ) && ( ( n % 100 != 11 ) ) 
            # 1, 21, 31, 41, 51, 61...
            :one
          elsif
            ( [2, 3, 4].include?(n % 10) \
            && ![12, 13, 14].include?(n % 100) )
            # 2-4, 22-24, 32-34...
            :few
          elsif ( (n % 10) == 0 || \
            ![5, 6, 7, 8, 9].include?(n % 10) || \
            ![11, 12, 13, 14].include?(n % 100) )
            # 0, 5-20, 25-30, 35-40...
            :other
          end
        }
      }   
    }   
  }   
}

And here is what our locales looks like for translating the noun ‘user’:

user:
  zero: пользователей
  one: пользователь
  few: пользователя
  other: пользователей

The above mapping helps us solve the initial problem with pluralized translations, but wait, there’s more complexity ahead!

Contextual Changes (e.g. Nominative vs. Genitive)

In addition to complexities with pluralization, I had to heavily rely on our client to further differentiate noun declension. I’m not a linguist nor an English teacher, but my best explanation here is that there is a difference in noun endings if it is nominative vs. genitive. For example ‘Users’ vs. ‘List of Users’ uses the same pluralization of ‘user’ in English, but in Russian and many other languages, the context influences the word ending here.

What does this mean for us? It means that simply calling t('user', count: 1) or t('user', count: 5) may not provide the correct localization and pluralization because the text in front of or behind the translation influences its declension. Therefore, we can’t just have the zero, one, few, and other mapping as shown in the above code example.

Enter Ruby on Rails, Rails gems (admin & breadcrumbs)

In our Ruby on Rails application, we use RailsAdmin, a gem to add admin functionality to our application. RailsAdmin, and other gems that we use, use generic formulas of translations based on the pluralization code.

Examples of locales strings are:

"List of %{model_label_plural}"
"%{model_label_plural}"
"New %{model_label}"
"Edit this %{model_label}"
"%{model_label}"

These formulas work fine for English, but they are too simplified for the contextual changes that I previously described.

Because RailsAdmin is a gem, that means I can override specific elements of it to accommodate Russian, and here’s a short list of how we accomplished this:

Retrieved a rails_admin.ru.yml as a starting point.
In some cases, removed model_label or model_label_plural entirely from some translations to make more generic messages, e.g. instead of “User successfully saved”, we use some equivalent of “Successful.”
Added code to override RailsAdmin helper methods used in various parts of RailsAdmin navigation and text rendering.
Copy views from RailsAdmin source and override entirely to use custom translation mapping in the form of discrete strings.

Hindsight is 20/20

When I started working on localization here, I was trying to work within the constraints of the gem and the formulas it used, but I ultimately had to resort to custom overrides of various helper methods and views. While this is not the method I prefer to work with a gem (making the upgrade path more complicated), I felt that this was the best way to handle localization & pluralization, and allow our client to override these discrete strings in a custom_admin locale file. Unfortunately, I could not find existing support for Rails 5.0 and our gems to handle the localization that I needed, so I would likely approach it similarly in the future.

Musica Russica is one of our Ruby on Rails ecommerce clients. The founder, Dr. Vladimir Morosan, was extremely helpful in completing the translation (and corresponding explanation to a software engineer) of a new Ruby on Rails 5.0 site.

Debugging Localization in Rails

2013-04-01T00:00:00+00:00

Rails offers a very extensive library for handling localization using the rails-i18n gem. If you’ve done any localization using Rails, you know that it can be difficult to keep track of every string on your web application that needs translation. During a recent project, I was looking for an easy way to visually see translation issues while browsing through the UI in our application.

Missing Translations

I’ve known for some time that when I was missing a translation for a given text that it would appear in the HTML with a special <span> tag with the class translation_missing. So in my global CSS I added the following:

.translation_missing { background-color: red; color: white !important; }

Now when I viewed any page where I had forgotten to add a translation to my en.yml file I could see the text marked in bright red. This served as a great reminder that I needed to add the translation.

I’m an avid watcher of my rails log while I develop. I almost always have a terminal window right next to my browser that is tailing out the log so I can catch any weirdnesses that may crop up. One thing that I thought would be nice is if the log showed any translation issues on the page it was loading. After some research, I found that the I18n gem used by Rails doesn’t give you any obvious hooks for translation errors. There is, however, a section in the Rails I18n Guide for adding custom exception handlers for translation issues and this is where I started with something like this in an initializer:

module I18n
  def self.just_raise_that_exception(*args)
    Rails.logger.debug args.join("\n")
    raise args.first
  end
end

I18n.exception_handler = :just_raise_that_exception

This got things started for me. After some small modifications to the logger line, I had the output that I wanted and to make things really stick out, I added some color using the term-ansicolor gem and came up with this:

def self.just_raise_that_exception(*args)
  require 'term/ansicolor'
  include Term::ANSIColor
  Rails.logger.debug red("--- I18n Missing Translation: #{args.inspect} ---")
  raise args.first
end

I18n Fallbacks

After using this solution for a while I ran into another issue. When I would change the locale in my app to something like es (Spanish) and look for translation issues, I was noticing some text that wasn’t being translated but it wasn’t being marked as red by my CSS. When I looked at the text further I noticed that it wasn’t even being surrounded by the <span class="translation_missing"> tag.

As it turned out, I did have a translation for that text in English, but not in the language that was set to my current locale. The reason for this is what I18n refers to as Fallbacks. Fallbacks tell the I18n what alternate, or default, locale to “fall back" to if a translation isn’t available for the current locale. By default, the fallback locale is en. Since I had a translation for that text in my en.yml there was no indicator that I had “fallen back" even though it was obvious that there was a translation issue.

Coming up with a way to be notified of fallbacks wasn’t nearly as simple as my initial solution. After a lot of googling and reading in StackOverflow, I found that perhaps the best solution was to override the translate method in the I18n gem. This sounds really scary, but it actually wasn’t too bad. Back in my initializer, I removed the solution that I had originally come up with and added the following:

module I18n::Backend
  module Fallbacks

    # To liven things up a bit
    require 'term/ansicolor'
    include Term::ANSIColor

    def translate(locale, key, options = {})
      # First things first, if there is an option sent, decorate it and send it back.
      return fallback_message(locale, key, super) if options[:fallback]

      default = extract_non_symbol_default!(options) if options[:default]

      options[:fallback] = true
      I18n.fallbacks[locale].each do |fallback|
        catch(:exception) do
          # Get the original translation
          translation = super(fallback, key, options)

          # return the translation if we didn't need to fall back
          return translation if fallback == locale

          # return the decorated fallback message if we did actually fall back.
          result = fallback_message(locale, key, translation)
          return result unless result.nil?
        end
      end
      options.delete(:fallback)

      return super(locale, nil, options.merge(:default => default)) if default

      # If we get here, then no translation was found.
      Rails.logger.debug red("--- I18n Missing Translation: #{locale}::#{key} ---")
      throw(:exception, I18n::MissingTranslation.new(locale, key, options))
    end

    # Added this method to log the fallback and decorate the text with a <span> tag.
    def fallback_message(locale, key, fallback_text)
      return nil if fallback_text.nil?
      keys = key.to_s.split(".")
      return fallback_text if keys.first == 'platform_ui'

      Rails.logger.debug yellow("--- I18n Fallback: #{locale}::#{key} ---")
      %(<span class="translation_fallback" title="translation missing: #{locale}, #{key}">#{fallback_text}</span>).html_safe
    end

  end
end

With this initializer in place, I added the following CSS to my global stylesheet:

.translation_fallback { background-color: green; color: white !important; }

Now all missing translation errors and fallbacks were noticeable while browsing the UI and all translation issues were logged to my development log. Now obviously, I don’t want these things showing up in production so I wrapped the whole thing in a if Rails.env.development? conditional. I could also think of times, like while working on implementing design, that I don’t really care about translation issues as well, so I added a flag for turning it off in development as well.

You can see my entire solution on a gist over at GitHub. It was suggested by a fellow colleague that I should turn this into a gem, but I didn’t see the need if all you had to do is copy and paste this initializer. If a gem is something you’d like to see this in, please let me know and I’ll consider packaging it up.

Spree vs. Magento: Feature List Revisited

2010-07-13T00:00:00+00:00

A little over a month ago, I wrote an article on Spree vs. Magento Features. Recently, a client asked me to describe the features mentioned in that article. I thought this was another great opportunity to expand on my response to the client. So, here I am, revisiting ecommerce features in Spree and Magento. The original article can be referenced to compare availability of these features in Spree and Magento.

Features on a Single Product or Group of Product

Product reviews and/or ratings: functionality to allow customers to review and rate products. See a Backcountry.com product page for an example.
Product QnA: functionality allow customers to ask and answer questions on products. See a Backcountry.com product page for an example.
Product SEO (URL, title, meta data control): functionality to allow site administrators to manage product URLs, product page titles, and product meta data.
Advanced/flexible taxonomy: functionality to build a custom taxonomy / navigation structure for product browsing. For example, build multiple categories and subcategories with complex hierarchy. The taxonomy at Spree’s demo includes two categories of brand and category and subcategories in each.
SEO for taxonomy pages: functionality to allow site administrators to manage taxonomy URLs, taxonomy page titles, and taxonomy meta data.
Configurable product search: functionality to allow the developers and site administrators to adjust parameters used in search, such as products to show per page, and to show products with no on hand stock.
Bundled products for discount: functionality to allow site administrators to create bundles or group products together and then apply a discount to the entire bundle. For example, product X, Y and Z purchased together will yield a $10.00 discount.
Recently viewed products: functionality to show customers products they recently visited. This can be displayed on other product pages or the navigation pages to aid in navigation back to those products if the user would like to revisit the products. See the image below for an example of this functionality in action at Paper Source.

Soft product support/downloads: functionality to sell soft products such as mp3 or pdf files.
Product comparison: functionality to allow customers to compare multiple products, such as a comparison of price or technical features. See Backcountry.com for an example.
Upsell: functionality to encourage the customer to purchase a similar product from a higher price point, or to purchase an add on, may or may not include the functionality to allow site administrators to manage the upsell products.
Cross sell: functionality to encourage the customer to purchase related items, may or may not include the functionality to allow site administrators to manage the cross sell products. See the image below for an example of this functionality at Backcountry.com after adding an item to the cart.

Related items: functionality to display related items on product pages, may or may not include the functionality to allow site administrators to manage the related products.
RSS feed of products: functionality to produce a RSS feed with product detail releases. steepandcheap.com offers a RSS feed, however, they are unique in that they offer a one deal at a time business model, so the RSS feed contains a stream of products for sale. This may or may not include the functionality to allow site administrators to manage the RSS feed contents.
Multiple images per product: functionality to allow site administrators to upload multiple products per image. See a Spree demo product for an example.
Product option selection (variants): functionality to allow site administrators to create and manage variants for products to offer multiple variants per product, such as variants by size and color. See a Spree demo product for an example.
Wish list: functionality to allow customers to create product wish lists. See Amazon.com for a description of their wish list functionality.
Send product email to friend: functionality to allow customers to send emails to their friend to visit a specific product.
Product tagging / search by tagging: functionality to allow site administrators to assign tags to products for navigation or searching. See CityPass’s blog for an example of tag use in a content management system; in ecommerce context, the tags would navigate to a set of products instead of a set of blog articles.
Breadcrumbs: functionality that renders the product navigation hierarchy on navigation and product pages to allow customers to navigate to previous pages visited. See a Spree demo navigation page for an example.

CMS Features

Blogging functionality: functionality to allow site administrators to create, manage and display blog articles.
Static page management: functionality to allow site administrators to create, manage, and display static pages such as “About Us”, “Information”.
Media management: functionality to allow site administrators to create, manage, and display media such as images, video, audio. See the image below for an example of WordPress’s dashboard for content management.

Contact us form: functionality to allow customers to submit a request for contact. See End Point’s contact page for an example.
Polls: functionality to allow site administrators to create and manage basic polls, functionality to allow customers to submit answers to basic polls.

Checkout Support

One page checkout: functionality to allow customers to complete checkout on one page, rather than move forward through checkout through multiple address, payment pages. See Paper Source or Backcountry.com’s checkout processes for examples.
Guest checkout: functionality to checkout without creating a user account. Checkout at the Spree demo without being logged in for an example.
SSL support: functionality to configure use of SSL during checkout. In Spree’s case, the site administrator may turn SSL off during development and on during production.
Discounts: functionality to allow customers to apply discount coupons to orders for a percentage or dollar amount reduction.
Gift certificates: functionality to allow customers to purchase and use gift certificates as credit for purchases.
Saved shopping cart: the functionality to save the products in a customers shopping cart so their shopping cart will be pre-populated on their next visit.
Saved addresses: functionality to allow customers to create and manage addresses to be selected during checkout for billing or shipping rather than requiring the customer to re-enter their address. See the image below for an example of using saved addresses during Backcountry.com’s checkout.

Shipping Support

Real time rate lookup (UPS, USPS, FedEx): the functionality to request rates from UPS, USPS, or FedEx during checkout for more accurate rate pricing rather than using a flat shipping rate.
Order tracking: functionality to allow the site administrators to enter order tracking information and allow the user to review that tracking information, may or may not include sharing this information in a “Your order has been shipped” email.
Multiple shipments per order: functionality to allow site administrators to split orders into multiple packages if specific products can not be shipped at the same time or can not be shipped together. See the image below for an example of Spree’s backend shipping interface.

Complex rate lookup: functionality to calculate ship rates based on weight or price.
Free shipping: functionality to offer free shipping.

Payment Support

Multiple payment gateways: integration of multiple payment gateways such as Authorize.NET, Beanstream, Paypal, SagePay, etc.
Authorize.Net: integration of the Authorize.Net payment gateway; may or may include the use of profiles (Authorize.Net CIM).
Authorize and capture versus authorize only: functionality to allow site administrators to configure whether or not credit cards should be authorized only during checkout completion or authorized and captured. If the credit card is authorized only, site administrators may finalize an order by capturing on the backend interface.
Google Checkout: integration of Google Checkout.
Paypal Express: integration of Paypal Express.

Admin Features

Sales reporting: the functionality to display sales statistics, such as profits on sales or year-over-year sales.
Sales management tools: functionality to allow site administrators to create and manage product sales. For example, the site administrator might create a 50% off sale to cover 25% of the products to begin in a week and end in two weeks.
Inventory management: functionality to allow the site administrator to manage individual inventory units and their current state (on_hand, shipped, backordered) and order assignment.
Purchase order management: functionality to allow the site administrator to create and manage purchase orders. See the image below for an example of a potential backend interface for purchase orders in Spree.

Multi-tier pricing for quantity discounts: functionality to allow customers to buy large quantities of products at a discount, the functionality to allow the site administrator to manage the large quantity product discounts.
Landing page tool: functionality to create custom landing pages that may include targeted content or products, typically used for advertising or marketing.
Batch import and export of products: functionality to allow the site administrator to import and export products via admin interface or script rather than entering each product individually.
Multiple sales reports: See “Sales reporting” above.
Order fulfillment: functionality to allow site administrators to manage fulfillment (inventory selection, shipping) of orders.
Tax Rate Management: functionality to manage tax rates per zone, where zones are defined by states and/or countries. Note that in Spree, zones can only be defined by a combination of states and countries and tax rates can be tied to one or more zones.

User Account Features

User addresses: See “Saved addresses” above.
Feature rich user preferences: integration of various user account tools, such as address management, profile management, order review, etc.
Order tracking history: functionality to allow a customer to lookup their order history, may or may not include order tracking information.

Site Wide Features

Extensibility: functionality to extend the ecommerce core with modular components.
Appearance Theming: functionality to change the appearance of the site.
Ability to customize appearance at category or browsing level: functionality to create and manage custom and varied appearances for product browsing pages. For example, the categories “Jackets” and “Pants” may have different appearances, motivated by marketing or advertising.
Localization: the functionality to translate the ecommerce site to a different language. See the image below for a small example of localization in action in Spree.

Multi-store, single admin support: functionality to manage multiple stores from a single administrative location. An example of this might include http://store1.endpoint.com/, and http://store2.endpoint.com/, where both can be managed at http://admin.endpoint.com/.
Support for multiple currencies: functionality to translate product prices between currencies.
Web service API: functionality to retrieve data from the ecommerce application for third party use. See Spree’s documentation on the Spree API.
System wide SEO: general site-wide SEO functionality including features such as sitemap, googlebase integration, URL management, page title management.
Google Analytics: functionality to allow site administrators to create and manage Google Analytics Ids, functionality to track traffic and conversion on the frontend.
Active community: an active developer community with frequent core and extension contributions.

Most of the features described above are well known to ecommerce developers, but this list might also serve as a good checklist to review with a potential client during the estimate process to make sure expectations of an ecommerce platform are managed, especially with a young platform such as Spree where some features are not yet included in the core.

PubCon Vegas Day 2: International and Mega Site SEO, and Tools for SEO

2009-11-12T00:00:00+00:00

On the second day of PubCon Vegas, I attended several SEO track sessions including “SEO for Ecommerce”, “International and European Site Optimization”, “Mega Site SEO”, and “SEO/SEM Tools”. A mini-summary of several of the sessions is presented below.

Derrick Wheeler from Microsoft.com spoke on Mega Site SEO about “taming the beast”. Microsoft has 1.2 billion URLs that are comprised of thousands of web properties. For mega site SEO, Derrick highlighted:

Content is NOT king. Structure is! Content is like the princess-in-waiting after structure has been mastered.
Developing an overall SEO approach and organization to getting structure, content, and authority SEO completed is more valuable or relevant to the actual SEO work. This was a common theme among many of the presentations at PubCon.
Getting metrics set up at the beginning of SEO work is a very important step to measure and justify progress.
Don’t be afraid to say no to low priority items.

Most developers deal with a large amount of legacy code. Derrick discussed primary issues when working with legacy problems:

Duplicate and undesirable pages. For Microsoft.com, managing and dealing with 1.2 billion pages results in a lot of duplicate and undesirable pages from the past.
Multiple redirects.
Improper error handling (error handling on 404s or 500s).
International URL structure can be a problem for international sites. Having an appropriate TLD (top level domain) is the best solution, but if that’s not possible, a process should be implemented to regulate the international urls.
Low Quality Page Titles and Meta Tags. For large sites with hundreds of thousands of pages, it’s really important to have unique page titles and meta descriptions or to have a template that forces uniqueness.

In summary, structure and internal processes are areas to focus on for Mega Site SEO. Legacy problems are something to be aware of when you have a site so large where changes won’t be implemented as quickly as small site changes.

In International and European Search Management, Michael Bonfils, Nelson James, and Andy Atkins-Krueger discussed international SEO and SEM tactics. Takeaways include:

In terms of international search marketing, it’s important to incorporate culture into search optimization and marketing. If it works in one country, it may not work in another country and so don’t offend a culture by not understanding it. Some examples of content differences for targeting different cultures include emphasizing price points, focusing on product quality, and asserting authority or trust on a site.
It’s also important to understand how linguistics affects your keyword marketing. Automatic translation should not be used (all the speakers mentioned this). A good example of linguistics and search targeting is the use of the search term “soccer cleats”, or “football boots”. In England, the term “football boot” has a very small portion of the traffic share, but singular terms in other languages (“scarpe de calcio”, “botas de futbal”) have a much larger percentage of the search market share. Andy shared many other examples of how direct translation would not be the best keywords to target (“car insurance”, “healthcare”, “30% off”, “cheap flights”).
Local hosting is important for metrics, linking, and to develop trust. Nelson James shared research that shows that 80% of the top 10 results of the top 30 keywords in china had a ‘.cn’ top level domain, but the other top sites that were ‘.com’ sites are all hosted in china.
Other technical areas for international search that were mentioned are using the meta language tag, pinyin, charset, and language set. Duplicate content also will become a problem across sites of the same language.
It’s important to understand the search market share. In Russia, Google shares 35% of the search market and Yandexx has 54%. In China, Baidu has 76% and Google has 22%. There are some reasons that explain these market share differences. Yandexx was written to manage the large Russian vocabulary that Google does not handle as well. Baidu handles search for media better than Google and search traffic in China is much more entertainment driven rather than business driven in the US.

In the last session of the day, about 100 tools were discussed in SEO/SEM Tools. I’m planning on writing another blog post with a summary of these tools, but here’s a short list of the tools mentioned by multiple speakers:

SEMRush
Google: Keyword Ad Tool, Webmaster Tools, Adplanner, SocialGraph API, Google Trends, Analytics, Google Insights
SpyFu: Kombat, Domain Ad History, Smart Search, Keyword Ad History
SEOBook
SEOmoz: Linkscape, Mozbar, Top Pages, etc.
MajesticSEO
Raven SEO Tools: Website Analytics, Campaign Reports

Stay tuned for a day 3 and wrap up article!

Spree 0.4.0 Released

2008-10-10T00:00:00+00:00

Spree 0.4.0 was officially released today. Spree is a complete open source ecommerce platform written for Ruby on Rails. While Spree technically works “out of the box” as a fully functional store, it is really intended to serve as a strong foundation for a custom commerce solution. Like Rails, Spree is considered to be “opinionated software”, and it does not seek to solve 100% of the commerce needs of all possible clients. Developers are able to provide the missing functionality by using the powerful extension system.

The current release of Spree contains many signficant improvements from the previous 0.2.0 release. Some of the highlights include:

Rails 2.1 support
SEO improvements
Security enhancements
Public assets for extensions
Mailer templates for extensions
VAT inclusive pricing
Taxonomy

Most open source projects in the Rails space are maintained by a single individual and tend to be limited in scope. For Spree we seek to create a large and healthy open source community similar to the ones found in more mature languages and frameworks. The Spree project has received contributions from over twenty different developers and has been translated into five additional languages.

I created Spree in late 2007, and End Point later became an official sponsor of the Spree project and employs me and several other Spree contributors.