jQuery Forum

This is definitively  an area that needs work.  Some consideration needs to be given to fonts and CSS, some fonts are going to take more room, on some widgets (as will some words), for example Lao script. Some browsers support the language pseudo-class: :lang too.

Also it should made easy to get the translations from the server-side. e.g in Ruby on Rails, I use a plug-in called Babilu to generate JSON lang strings from rails and add supported functions, here is the api docs, which may be useful for ideas


Babilu
=======

Babilu converts all your translations into JavaScript so you can use them on
the client side. It mimicks the Ruby/Rails I18n API and works in pretty much the
same way:

//JavaScript
I18n.defaultLocale // "en"
I18n.locale // Whatever the locale has been set to on the server

I18n.t('hello') // "Hello World"
I18n.t('messages.invalid', {scope:['activerecord', 'errors']})  // "is invalid"
I18n.t('activerecord.errors.template.header', {count:4, model:'pony'}) // "4 errors prohibited this pony from being saved"

I18n.translations.en.ponies = {one: 'I have a pony', other: 'I have {{count}} ponies'};
I18n.t('ponies', {count:5}) // "I have 5 ponies"

The only difference is that because JavaScript doesn't have symbols we can't
easily differentiate between keys and values in the "defaultValue" option. A workaround
is used in which strings starting with ":" are considered to be keys and are used for
looking up additional translations:

I18n.t('doesntexist', {defaultValue:'humbaba'}) // "humbaba"
I18n.t('doesntexist', {defaultValue:':hello'}) // "Hello world"
I18n.t('doesntexist', {defaultValue:[':alsodoesntexist', 'The Sasqutch: Fact or Fiction?']}) // "The Sasquatch: Fact or Fiction?"

This plugin depends on http://github.com/toretore/lucy


Copyright (c) 2008 Tore Darell, released under the MIT license


Justin

babilu sounds interesting. afaik, rails uses the gnu gettext tools for managing translations. There is no reason we can't use these for javascript as well. Unfortunately, GNU gettext only handles strings inside your code and can't handle strings in the html of your application

My issue w/ it is that all your translations are in a global namespace. I think each plugin should have its translations in its own namespace.  

I can't use Babilu as my applications are all desktop apps that happen to run in the browser.

As far as CSS, that is a difficult problem. I think the only workable solution is to have add an additional css file that overrides other css styles for the purposes of fonts and Right-to-left text.

Didn't read the entire thread to, but my two cents on this as well...
All of our translations are managed in a GUI which is saved to a database using PHP.

I would very much like to see an easy plugin that would get all translations strings it requires using one ajax call to the server that is able to return JSON to initialise the translation strings on the client side...

Not sure if that would make sense, but it would to me... :)

I'm confused as to why you think there is any forking at all. Datepicker has the most extensive i18n and all of the i18n files are nothing more than what you've described would be in jquery.plugin_name.locale_name.json. Same goes for other plugins such as dialog, which has a closeText option.

The difference is whether you pass the values as options or whether the plugin has an extra level of functionality that does it automatically based on some other set of values that's only tangentially related to the plugin. The overwhelming majority of the time you'll only use a single locale within a page, so exposing the locale info as options is extremely easy to work with because you can just override the default values for those options and be done with it.

Can you provide specific areas where you think providing a full i18n system would be beneficial to UI?

Hey Bryan,

I understand why a full i18n system is important, what I'm trying to figure out is whether or not UI plugins need to care whether or not such a system exists. We're absolutely interested in providing full i18n support and making it extremely easy to use. I'm just not currently convinced that going with the status quo (baking the equivalent of gettext into everything) is the correct answer.

Scott, you bring up that both dialog and datepicker maintain their own closeText values. Once we have 5-6 plugins on a page that store their own closeText string for the same locale, doesn't it make sense to centralize this information?

Your proposal had values split out per plugin as well. Neither require translation duplication:

1. $.i18n.es = {
2.     hello: "hola",
3.     goobye: "adiós"
4. };
5. $.i18n.plugin1.es = {
6.     hello: $.i18n.es.hello
7. };
8. $.i18n.plugin2.es = {
9.     hello: $.i18n.es.hello,
10.     goodbye: $.i18n.es.goodbye
11. };

This could even be simplified because we know that no plugin will ever use a value that doesn't exist globally:

Based on the code above, we can support several use cases without the plugin doing any i18n work:

I've created a wiki page at http://wiki.jqueryui.com/i18n to gather use cases, goals and ideas. Let's keep this discussion going but capture the important pieces on the wiki.

I have done more thinking on this issue and plan to refactor jquery-i18n to closely match the API that google extensions provides http://code.google.com/chrome/extensions/i18n.html

Scott, do you think u might have time to chat w/ me regarding this issue some time this week?

I am signed on to #jquery most of the time that I am awake, however I at UTC+5:45 (Nepal) which might be quite removed from your timezone.