New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Localization of Apertium Tools #28
Comments
I think gettext is still pretty much the standard. |
We use ICU anyway, so we have access to https://unicode-org.github.io/icu/userguide/locale/ , https://medium.com/i18n-and-l10n-resources-for-developers/the-missing-guide-to-the-icu-message-format-d7f8efc50bab |
Also, we'd need to decide on what not to localize. E.g., floating point weights and other data that is used in pipes must have a single fixed format, regardless of locale. |
So things like If we start translating error messages, we should give them unique error codes, e.g. |
Added to https://wiki.apertium.org/wiki/Ideas_for_Google_Summer_of_Code GSoC Coding Challenge: Make a trivial C++ Hello World app where the Hello World string is translated using ICU's API and external file format. Tools that should be localized https://github.com/topics/apertium-core :
All communication should ideally go via our IRC channel (Freenode #apertium) or apertium-stuff mailing list. We don't use issues for chatting. |
The error codes are good for googlability even if there's no localization for sure. For localized number formats I'd say, if it's part of the stream format that needs to be fixed for tools, then the English numbers hard-coded are a good thing, but for the rest it's ok to use the format you get with the locale as well. As a translator I'd prefer to have a text-editor editable format like gettext's po, which icu seems to support too, if possible. I really dislike the fact that most floss projects these days are moving towards only being localizable with some horrible browser-based apps... |
If I understand this correctly the problem that we need to solve here is about localizing the texts used in different applications to different languages based up on the |
Only the console apps matter for this. And localizing a Hello World app using ICU should teach you all you need to know about how it reacts to locale. |
Also, all communication should ideally go via our IRC channel (Freenode #apertium) or apertium-stuff mailing list. We don't use issues for chatting. |
Okay I will join the channels |
I was just thinking that whoever ends up working with these strings that there's a lot of room for improvement for apertium tools printouts... for example when man compiles a thing the only printout is like:
this is probably good for debugging for someone who has worked with the tools but for usability it should be rewritten in human languages and translateable. |
I was talking to @jonorthwash about localization and it came up that all our command line tools are currently hardcoded as English-only and it would be good if this were otherwise.
I'm uncertain how to effectively/efficiently implement this, but if anyone has any ideas, I'd be happy to do the setting up (since I'm probably digging through all the string handling code this summer anyway).
The text was updated successfully, but these errors were encountered: