WIP Translations

[buma]

This is work in progress for making otp.js translatable. Results can be seen here.

Translations are implemented in gettext workflow. In Javascript files locale is included and then singular translations are used like locale.gettext("wanted transation"). Plural like locale.ngettext(singular_key, plural_key, value).

In handlebars translations are used with help of handlebars helpers {{_ "singular"}} is for singular translations. {{__pgettext "context" "string"}} is for context singular translations. Other helpers weren't needed for now.

Translatable strings are extracted from JavaScript and Handlebar files into lib/locale files. Each language has each own. Those can then be translated with Poedit or other web or desktop based translator programs. Po files are then converted to json with po2json. And is then used by translation library.

On first visit of a page language is detected from navigator languages (first wanted language that is available is used), then navigator language and userLanguage are tried. If all detection fails English is used. If language is detected wanted language is saved in a cookie and is read from a cookie on next visit. Language can also be changed from a dropdown. This currently adds wanted language as a url parameter and reloads a page. Which is ugly.

All language related tasks are in lib/localization.js

in config.js I added for each available language date/time format and if metric is used. This is also changed when language is changed.

I used Jed library for translations. And for extracting translatable strings from Handlebars templates I use Jspot and for extracting from javascript files xgettext. I plan to use jsxgettext because it also supports translator comments in handlebar files but it doesn't support context with translations yet.

Basically every visible string is translatable missing are:

• [ ] Map Layer names
• [ ] Map attribution
• [ ] Geocoder input fields help text (" write 5 characters" etc)
• [ ] Icon instead of text for switch languages
• [ ] arrive by /depart from option isn't selected when first visiting website

[buma]

@trevorgerhardt: can you please look if this is OK or should localization Handlebar helpers be in handlebar file?

[buma]

Localization for geocoding is weird. Seems that in version of select2 we are using currently (3.4.8) you need to load file with your language localization before you initialize first select2 input field.

As far as I can see all the localization files are loaded (last loaded is Chinese) before select2 input field is initialized and language of input field is English.

In new select2 (version 4.0.0) it seems all you need to do is to set language: "language name" when select2 field is initialized.

I'm not sure if we can update to version 4.0.0 since currently we are using fork of select2 maintained by @kpwebb. It seems that changes aren't large. Some string changes and some style differences.

[abyrd]

Hi @buma, I was just reviewing this with @trevorgerhardt. This general approach is leading to an ever-growing amount of translation in the client. We'd like to restructure the OTP responses to allow much more translation to occur on the server side, to the extent that even a client with very basic translation handling can render an OTP response. I have created ticket https://github.com/opentripplanner/OpenTripPlanner/issues/2070 to discuss this issue.

[abyrd]

@buma, I know you already did a lot of research on JS GetText libraries, which is understandable since we framed this work as bringing otp.js in line with existing features of the default OTP client. Would it be straightforward to consolidate more translation on the server side, and do most pluralization etc. on the server side instead?

[buma]

Web API would need to be changed a little. PO files can stay the same. It would be best if translation itself would be done with gettext-commons or other gettext compatible libraries. Extraction of strings should work with plain xgettext.

Creation of text itself should probably happen in step generation itself.

It seems that Java 8 now supports better date and time handling and also localized date time. I'm not sure it supports "showing date format for germany" or you need to specify format yourself, but since we needed to specify specific short formats in client also this shouldn't be a problem.

Maybe we can keep steps as they are right now in API response but add parameter localize and if this parameter is used server localization is used.

[abyrd]

On 31 Jul 2015, at 14:32, Marko Burjek notifications@github.com wrote: Creation of text itself should probably happen in step generation itself.

In terms of implementation, yes I think this translated text would be generated when converting the path to a response.

Maybe we can keep steps as they are right now in API response but add parameter localize and if this parameter is used server localization is used.

Yes, it looks like everyone is leaning toward this solution. We’d keep the walksteps the same, but at various points in the API response (per walk step, per transit leg) we’d have a short and long translated text field. We should switch the main OTP client library (otp,js) to use that translated text feature.

[tiagofassoni]

Hello. I want to deploy otp.js for Brazil (more specifically, São Paulo). Although the current state of translations is not optimal, they could be used and refactored or changed later.

I fully understand and agree with moving more of the translations to the server, but the ticket implies some heavy lifting will be needed there. Is it possible to move the translations to master, as it is, and afterwards change them?

Thanks!

[abyrd]

Hi @tiagofassoni. Can you explain what you mean by "heavy lifting"? My understanding is that we would just be copying translation files from one repo to another, then doing some manual merging of client side and server-side translation files. Performing or editing a translation is not really heavy work, just tedious: it's filling out a bunch of entries in a text file.

And what do you mean by "move translations to master"? Do you mean move translation files from otp.js to OpenTripPlanner?

[tiagofassoni]

Hey, @abyrd. I'm sorry for not being clear enough. Let me try to explain myself a little better:

I understood the translation pull request of otp.js is not going to be merged into master branch because there would be some duplicated translation work in otp.js and in the opentripplanner server. I also understood that the process in opentripplanner itself is going to take some work.

So I'm asking you guys to consider merging now, as it is. And obviously, I would translate it to brazilian portuguese.

I could use the translationsMaster repo, but I prefer to check with you guys before.

Thanks!

[abyrd]

Ah, thanks for the explanation @tiagofassoni. My impression is that @buma is mostly done with the server-side localization and it won't be too difficult to adapt otp.js to use it. So what would would be best is to have your assistance working on the new server-side translations, as well as the simpler otp.js UI element translations. I think this will be feasible within a few days.