WIP Translations #66
WIP Translations #66
Conversation
Added Jed localization library as a local component. Added language detection to utils (currently always returns sl) Added lib/localization which loads Jed sets detected language and exports module and handlebar localization helpers Currently normal and context translations helpers are supported In code localization is used in bike views and models JSON files are currently from JED leaflet
This helper localized exit numbers in roundabouts. I moved to localization since all the localized stuff is set there. It localizes exits from 1-10. For roundabouts with larger number of exits it just returns number and ".".
And added extracted POT template, PO files and generated json files. Currently po files have a lot of unused translations which are left over old OpenTripPlanner po files. When adding translations is finished those will be removed. But they re left for now since if the same english string is used in otp.js when po files are updated same translation is used if the string existed in previous translations. Currently translations are extracted from handlebars with jspot and from javascript files with xgettext. I'll probably replace at least jspot with jxgettext since jspot doesn't recognises translator comments. But jxgetext doesn't support different context.
TODO: relativeDirection and ordinals need to be translated
Wanted locale is currently set language. This means that response is localized (localized street names, generic names (path, bike path, intersections x and y etc...)
Input date/time format is set based on locale value. Date/time itself is read as momentjs date in specific format Date: MM-DD-YYYY Time: hh:mm a This is date/time format that is send to the OTP
(Trip time, walking, driving time etc..)
Arrive -> Arrive at Depart -> Depart by Wheelchair accesible trip: -> Wheelchair accessible trip
First from queryString then from cookie and last from navigator language. Wanted language (if it isn't the default) is saved in a cookie.
Otherwise we get translation missing for each text. Since english language doesn't have translations, since source language is in english.
It updates translation files
Since localization will be needed in utils and this fixes circular dependency
not pure momentjs local aware format. This was made because all local aware moment.js time and date formats have year in them which is too long and looks bad in narrative display. So we specified our own formats for each language which are the same as lll moment.js formats only without the year.
Missing are those which are from select2 widget itself ("Write 5
charaters" etc.)
|
@trevorgerhardt: can you please look if this is OK or should localization Handlebar helpers be in handlebar file? |
|
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. |
|
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 opentripplanner/OpenTripPlanner#2070 to discuss this issue. |
|
@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? |
|
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. |
In terms of implementation, yes I think this translated text would be generated when converting the path to a response.
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. |
|
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! |
|
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? |
|
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! |
|
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. |
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 likelocale.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: