Closed lewadedun closed 7 years ago
It is planned and actually at the top of the list of things to do. There's still some open issues and I haven't hurried it much since not being allowed in the Jolla store has kept the user count low.
The issues are due to Poor Maps being a combination of QML, Python and JSON. The Qt translation system seems very primitive compared to e.g. gettext and I don't (yet) know how to best handle stuff. Had I been familiar the Qt translation system when I started, maybe I would have structured things differently, but I wasn't.
qsTr
and lupdate
.tr
, which is just an identity function that allows the strings to be extracted with pylupdate
, and then called qsTr
on the strings in QML. This works fine for plain strings, but not at all for any string formatting done in Python.So, yes I think this is important, especially now as Jolla seems to focus on markets with bad English skills. Any advice with the above would be appreciated.
And last I looked Transifex didn't support plural forms in Qt translation files. I have noticed that others use Transifex anyway, are they just avoiding plurals? I wonder if there's a better place to put translations?
Good questions. ) But, unfortunately, I can't help you, because I don't know programming, I'm just helping to translate the application ... (((
I don't know if it would fit your requirements, but you could take a look at https://hosted.weblate.org/.
Thanks. I'll take a look. Also, regarding web UIs, on the last community IRC meeting:
the community pootle got stalled quite close to going public because of the financial situation, hopefully we can get that forward sometime soon
http://merproject.org/meetings/mer-meeting/2015/mer-meeting.2015-12-17-14.30.log.html
I just moved another project of mine, Helsinki Transit Stops, to use gettext po-files and Transifex for translations. Using gettext means that string formatting in Python and reading JSON etc. files in Python can be handled correctly. The po-files are converted to the Qt qm format when building the RPM.
This system seems to work all right and I'll probably adopt that in Poor Maps as well. Plurals won't work in QML, but I think we can live with that (I won't leave them untranslated, they'll just be wrong, e.g. "1 apples").
https://github.com/otsaloma/helsinki-transit-stops/commit/0e7d8ca4205eeca3bdbb1a42b7710f5777d0793d https://github.com/otsaloma/helsinki-transit-stops/commit/897dc974e6ab03fb368c44905e70b3941f1a8343
So... What about localization? )))
@otsaloma You could always put "apple(s)" instead of "apples" so it's never wrong.
So... What about localization? )))
I haven't forgotten about it. I prioritized the adaption to different screens (the 0.25 release), but now i18n is back at the top of the things to do... well, right after a small API migration (#19). Maybe before the end of the year could be realistic.
You could always put "apple(s)" instead of "apples" so it's never wrong.
Plurals isn't too big of an issue as they're not used that much and mostly in places where the count is rarely singular or zero -- so I'd go with "%d apples".
In general, how to do the i18n is sufficiently clear, just doing the work remains.
Work begun: https://github.com/otsaloma/poor-maps/pull/31
Hi. Did you fix the issue with strings from JSON? I looked at it yesterday in OSMScout and found some working solution - I created qml file that is not added to build, but contains just strings from resources: https://github.com/Karry/osmscout-sailfish/blob/master/qml/l10n.qml Then, In qml where are these strings visible to users, I call qsTranslate("message", message)
I can update translations with lupdate
now.
@Karry I plan a similar approach, except via Python and gettext. I'll automate the string extraction with something like
sed 's/: \(".*"\)/: _(\1)/' routers/mapzen.json | xgettext --language=JavaScript --from-code=UTF-8 --keyword=_ --output=- -
When reading JSON files (in Python: poor.util.read_json), I'll call gettext
on the field values.
To expand on the JSON matter, what I ended up doing is marking translatable fields in JSON files with an underscore, e.g.
{
"attribution": "Data © OpenStreetMap, DataScienceToolkit, Flickr Shapefiles, GeoNames, Natural Earth, OpenGeoCode, Quattroshapes, Twofishes, Yahoo GeoPlanet",
"_description": "Geocoding based on open data sources",
"name": "OpenCage",
"source": "geocoder.opencagedata.com"
}
Because only a small part of all fields are likely to want to be translated and not even the same fields in all files. When read in Python, these marked field values are translated and the underscore prefix removed from the field name.
Extracting translatable strings from all JSON files turned out to be simple to do in one go with a piped command. From the Makefile
:
cat */*.json \
| grep '^ *"_' \
| sed 's/: *\(".*"\)/: _(\1)/' \
| xgettext \
--output=$(POT_FILE) \
--language=JavaScript \
--from-code=UTF-8 \
--join-existing \
--keyword=_ \
-
Code-wise all done (see merged #31). I'll upload the translations to Transifex soon, but please wait for the 0.28 release and announcement before translating as I'll still take a few days to test and might be updating strings in the source if I spot problems.
Ok
can be use lowercase letters?
"Share current position" is an item in the main menu, "Share Current Position" the title of the page that opens. Use capitalization rules of your own language in your translation.
ок
Could you support localization(e.g. using transifex) please?