Internationalization is the process of setting up your app in a way that it can be localized, whereas localization is the actual process of adapting your app for use in other locales, including translation, distance and time conversions, and different feature sets.
Mostly touching on first type Other aspects of second type: measurement, government/legal terms, dialect differences Translators should be aware of third type Maybe you could use some of the same tools E.G. kid and parent versions of site
Even if you don’t see a future where your app is localized, writing it with localization in mind will lead you to other good practices Very few things are just going to be tailored to just English speakers, esp. Considering how many languages are spoken in the US
Converting strings in your views to keys is an easy win that you can do RIGHT NOW
Translate: language (what language does this person speak?) Localize: measurement, etc. (where is this person from?) By default rails uses yml files, we’ll talk more about this later
Think about the scale of your app and how many strings you’re likely to need Hundreds? Thousands? At what point is it practical to store everything in yml? Customize yml files to be per-feature
Rails-18n - translations for errors - activerecord stuff - date formatting - much more Localeapp: webapp for storing translations Provides interface for translators to log in from Also tied into paid translation services Globalize Adds translations to ActiveRecord models Localize attributes If you have a blog with posts that need localized versions Geocoder Location-based locale selection I18n-tasks Report keys that are missing or unused. Pre-fill missing keys, optionally from Google Translate. Remove unused keys.
ActiveRecord also possible Frequency of access In-memory store probably preferable Caching issues
Any time you’re translating fragments or concatenating translated strings together, take a step back
Different syntax Verb may go at end of sentence Full sentence may be needed for conjugating/gendering Instead, use variables in a full sentence to drop in your own text Variable can be passed in with locale key
English:- zero & more than 1- 1Other languages may make different distinctionsDon’t hard code thisInstead, use the count variable
Gender Register (formal/informal) Context/specificity of word Korean has multiple words for “in”--one to denote a snug fit in a container, one to denote a loose fit
Some languages may use far less or more space to convey the same information Fit more characters in a space or adding a line, shrinking text Fixed height/width containers Think about this when writing CSS/doing frontend work General rule of thumb in English to French translation: French text will always take up more space
If everything is in one yml file, things get messy quick With everyone modifying a single yml file, merge conflicts are likely You also probably don’t want to give everyone who wants to change copy repo access Break up keys Submodule Database Separate repo Localeapp/other external source of truth
Concerns:- Ease of use - Audit trail - Ease of rollback- File size/complexity
Before you decide to internationalize for a given region, think about all these things- Other countries have different norms around privacy, religion, tracking- There may be legal issues, do not track, copyright, defamation- The same needs may not exist: healthcare, transport - Social and cultural differences: attitudes toward gay people, etc.
Before you decide to internationalize for a given region, think about all these things- Other countries have different norms around privacy, religion, tracking- There may be legal issues, do not track, copyright, defamation- The same needs may not exist: healthcare, transport
Finding Translations: Localization and Internationalization in Rails
Adventures in localization and internationalization
Defining our terms
Localization - the process of adapting internationalized software for a specific region
or language by adding locale-specific components and translating text
Internationalization- the process of designing a software application so that it can
potentially be adapted to various languages and regions without engineering changes
In plain English
Translating (and getting ready to translate) your app.
What is translation?
Language-English to French, French to Arabic, English to German, Swahili to
Esperanto, Spanish to Cantonese
Cultural-British to American, Portuguese to Brazilian, Canadian to Australian
Register-Formal to informal, professional to Twitter, AP style to MLA style
Who Am I?
Rails developer at Panoply
Interests in linguistics, translation, and language
Past life as a French major
So you want to localize your
When should you think about localization?
Think about your app and its possible audience. If your set of possible users is not a
subset of “US-based English speakers,” localization is something that should be on
When should you internationalize?
Before you need to. (Now.)
Don’t hard code strings into your views, use keys!
Rails localization conventions
Translate vs. localize
.yml files everywhere
There’s a lot built in for you
There’s a gem for that
Other possible database backends?
Or just edit the YML
The usual way
Or in a graphical YML editor
Things to consider
What needs to be translated?
Large blocks of text?
Lots of strings?
Who is translating it and what tools do they need?
But how does your app translate?
Think about cultural and legal implications and differences when choosing how to
localize and what countries and languages to localize for
Think about localization now
Your translators should have a good understanding of your app
Translation is hard
Know your audience