Skip to content
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

POT and PO usage for translations? #31

Open
martinjirku opened this issue Nov 23, 2018 · 4 comments
Open

POT and PO usage for translations? #31

martinjirku opened this issue Nov 23, 2018 · 4 comments

Comments

@martinjirku
Copy link

I am new to Racket... I would like to translate it to my own language - Slovak. I've started the translating by copying english english-string-constants.rkt to slovak-string-constants.rkt. I've updated files, but during the translation process I've missed out ", and I had to resolve bug to make my translation work again.

So I've found myself wondering how are changes handled? New strings, removed strings? How is the translation decoupled from the code?

In my professional experience on international projects we had very nice process for i18n by using gettext POT and PO files (more here):

  1. Developer specified strings in file like english-string-constants.rkt. Developer removed/add strings as needed in application.
  2. A tool extracted these strings to POT file.
  3. POT (and language PO file if it already existed) was provided to translators
  4. Translators used tool of their choice (there are plenty of them e.g. poedit) to translate strings. By opening PO file, specifying the POT (template) file, they were able to see, old-unused translations or newly added translations.
  5. After translation was done, updated PO files were transformed with some sort of script back to files like: slovak-string-constants.rkt

Because I like Racket and stuff around it, and I like to learn by doing, I would like to contribute to DrRacket project (string-constants) not only by translating, but by creating such a tool which would simplify translation and proofreading for non developers (including maintenance of new strings and removing non-used ones).

What do you think? Do you think it will improve project somehow?

@rfindler
Copy link
Member

As a general rule, we never change any string constants to avoid trouble with translators missing that they changed. We rename and delete old ones, and that gets noticed by setting the PLTSTRINGCONSTANTS environment variable and starting up DrRacket (although I see there is a lot to tend to in that output currently, so maybe it isn't being used).

One thing that'll be different in the Racket world from others is that the files like english-string-constants.rkt are actually programs, written in a custom language, and you can open them in DrRacket. In addition to helping with things like mismatched quotes (and spelling errors if you turn that on in the bottom of the "Edit" menu), it is not difficult to add more support to the language to help you do your work. And if you want to take this as a racket-learning experience that's definitely the way to approach the problem. This CACM article is a place to start to read about the philosophy behind this paragraph.

That said, reusing the support that others have built for things like PO/POT files does sound wise!

@alshopov
Copy link
Collaborator

alshopov commented Nov 23, 2018 via email

@rfindler
Copy link
Member

Sorry if I misunderstood your earlier comments! I don't know anything about po but plural (and word order when we want to drop a number or something computed into a string) is something that we struggle with for sure.

@martinjirku
Copy link
Author

martinjirku commented Nov 23, 2018

@rfindler I will look at it closer. Thank you very much for directions...

@alshopov Yeah, pluralization is not easy to do it right.

Currently I am using ICU message syntax, which is industry standards with support of all CLDR languages in JavaScript/C++. It's nicely done, we are able to do pluralization for all language our app supports. It would be nice to have in racket...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants