TelescopeJS/Telescope — pull request #526 by theosp (2014-11-18 17:52:59+00:00)
Title: Use the tap:i18n package as Telescope's i18n engine

Use [tap:i18n](https://github.com/TAPevents/tap-i18n) for i18n in Telescope.

Notes:

**1. Translations Keys:**

In [i18next](http://i18next.com/), and therefore in tap:i18n, it is common to use as translation keys all_lower_cased_underscored_sperated names, it is not officially advised, but [i18next documentation](http://i18next.com/pages/doc_features.html) follows this convention. [See also an example in another package that uses tap:i18n](https://github.com/francocatena/meteor-status/blob/master/i18n/fr.i18n.json).

There are three rationals for that:

i. You don't want translators to rely on the key when translating the project. The English string might change without the update of the key, because updating a translation key in a project that has more than a few language files is a long process that might result in bugs if not done properly.

ii. Periods and colons has special meaning i18next/tap:i18n.

iii. Once you start using special features of i18next, such as [context](http://i18next.com/pages/sample.html) it becomes really messy not to follow this convention.

I prepared [this script](https://gist.github.com/theosp/559117bed5fd6996694c) to perform the migration.

**2. Missing Translations:**

During the process of migrating Telescope to tap:i18n I found some strings that were missing from the translations files, they need to be translated, check commit: abe291a72ae99c6b1427ff44ad14c4d1d959f2a2

**3. Many parts of Telescope still need to be internationalized:**

Many strings in Telescope aren't encapsulated with the i18n method or helper.
Bold examples:
* The top search input placeholder "search".
* The: Top, New, Best,Digest, Daily strings in the view menu.
* The signup/login view.
etc.

**3. Consider making it possible for users to set their own interface language:**

Telescope right now is designed in a way that each project is translated to a single language. If you decide to allow each user to set its own language, tap:i18n can make it very easy using the TAPi18n.setLanguage() method.

You are welcome to try it by running in the console:

TAPi18n.setLanguage("es");
or

TAPi18n.setLanguage("zh");

The project language will still be useful to set the default language and the language for server messages.

**4. A new session variable, i18n_ready, that holds tap:i18n ready state:**

In the client, once a language other than English is in use (the English files are integrated to the bundle),
we have to load its strings from the server. We do this with an ajax call. In order to allow waiting for the project language to load reactively, I've added a new session variable: "i18n_ready". Its value changes from
false to true once the project language is ready.

**5. Consider using tap:i18n variables and count features, once integration is stable:**

I figured that it's better to make sure that everything continues to work the same way before we start using
tap:i18n features such as variables and count in places like:

./client/views/users/user_item.html:15:

{{i18n "Invited"}} {{invitedCount}} {{i18n "users"}}:

I think it should be done once the integration is considered stable.

That's all, Hope you'll like it!

[Daniel Chcouri](http://theosp.github.io)
MeteorSpark [Professional Meteor Services](http://www.meteorspark.com/)