search

fgpv-vpgf / fgpv-vpgf

The Reusable Accessible Mapping Platform (RAMP), also known as the Federal Geospatial Platform Visualiser (FGPV), is a Javascript based web mapping platform that provides a reusable, responsive and WCAG 2.0 "AA" compliant common viewer platform for the Government of Canada.
https://fgpv-vpgf.github.io/fgpv-vpgf/master/docs/#/
Other
45 stars 48 forks source link

Add a dirty bit to language translation #1921

Closed barryytm closed 7 years ago

barryytm commented 7 years ago

Add a dirty bit to the language translation file to indicate whether the French translation had been officially reviewed or not.

barryytm commented 7 years ago

Is just adding a new column for setting the value 1 if it was reviewed and 0 otherwise good enough?

james-rae commented 7 years ago

Where are you adding the column? What is the impact to the code that parses the csv file?

Also, be aware we can have more than two languages. E.g. this one has 3 https://github.com/fgpv-vpgf/fgpv-vpgf/blob/spanish/src/locales/translations.csv

AleksueiR commented 7 years ago

Yeah, each language should have a "dirty" column, and these should be ignored when converting to JSON. We used a gulp-csv-i18n plugin for conversion, but it's different with the webpack now.

milespetrov commented 7 years ago

Please review the webpack plugin I wrote for the CSV to inline JSON conversion. https://github.com/fgpv-vpgf/fgpv-vpgf/blob/develop/scripts/translations_plugin.js#L28

Make sure the plugin is updated to the new format standard. Feel free to ask me questions if you get stuck.

barryytm commented 7 years ago

Ok, I guess I will just put the dirty bit to the right of the translation then ignore it when converting to JSON in the plugin.

james-rae commented 7 years ago

So something like...

Description of pigdog,app.pigdog,Pig Dog,1,Cochon chien,1,perro cerdo,0
Description of meatball,app.meatball,Meat Ball,1,Boule de viande,0,Bola de carne,0

and then modify the plugin to skip columns that follow a language (i.e read first two, then read one, skip one, read one, skip one, ....)

milespetrov commented 7 years ago

I was always curious why we went the CSV route for translations. Maybe its worth looking into a standard format for our translations?

I came across one called XLIFF 2.0 which is XML based. Among other things, it includes state (initial, translated, reviewed, final). There are npm libraries that convert it to JSON.

http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html

AleksueiR commented 7 years ago

We did. In RAMP1 we used .po files which were then converted to .json as usual for consumption. However, our translation services don't know anything but Excel, so .po files had to be converted to .cvs before sending out for translation, converted back and re-integrated with existing translations. Not terribly difficult, but annoying and time-consuming. Also, WET uses the .csv approach to manage their translations, and they have many more languages and was considered a best practice at the moment.