Manually change a .po - Githubissues

skarampatakis commented 7 years ago

I have manually changed a value in the Greek localization .po

specifically this one

#: ../../../tmp/translation/haml-gettext-00000030.rb:2
msgid "Welcome to Gotham's Participatory Budgeting process"
msgstr "TEST"

Because I would like to change the default city's name and translate the string in greek.

I restarted the server but nothing happens. It still show the previous one. Is there anything else I need to run in order to update the localization? Or else I will have to change the view and hardcode the message.

I couldn't use the translation:sync command that connects to translation.io because it brings an error.

esebastian commented 7 years ago

As we are using a gettext based i18n system, the corresponding .mo file must be generated after the .po file is updated.

The translation.io service does that for us automatically, and thetranslation:sync rake task should we working. Let me check that and I'll come back to you, @skarampatakis.

esebastian commented 7 years ago

Hi @skarampatakis, everything should be now working as expected. Can you confirm that?

skarampatakis commented 7 years ago

Hi @esebastian, I tried to run bin/rails translation:sync but I get an error.

* Downloading YAML source editions.
rails aborted!
JSON::ParserError: 743: unexpected token at '<!DOCTYPE html>
<html>
<head>
  <title>Translation.io - The page you were looking for doesn't exist (404)</title>
  <style>

  </style>
</head>

<body>

  <div class="container" style="text-align:center;margin-top: 250px;">
    <a href="/">
      <img src="/logo-big.png">
    </a>
    <div style="font-family: Helvetica Neue, Helvetica, Arial, sans-serif; font-weight: 500;margin-top: -41px;margin-left:2px;text-transform:uppercase">
      404 - Page not found
    </div>
    <div style="margin-top: 80px">
      <a href="mailto:contact@translation.io">Contact us</a> for any question regarding this issue.
      <br/><br/>
      <a href="/">Back to the homepage</a>
    </div>
  </div>

</body>
</html>
'
bin/rails:4:in `require'
bin/rails:4:in `<main>'
Tasks: TOP => translation:sync
(See full trace by running task with --trace)

What I asked originally was, if we could translate some strings locally without having to interact with translation.io. This may be useful when in some cases, custom messages are required. Tranlation.io integration is great for the UI. But I think the message above and some other should be customizable per deployment. Perhaps organized in separate files also?

I have searched a bit and seems that I would need to install on my develop machine gettext and use something like msgfmt -o lang.mo lang.po to compile the .po. Could you confirm that something like this would work? I am not that familiar with gettext.

esebastian commented 7 years ago

Hi @skarampatakis,

I guess you're getting that error because the API key token is not available to the translation:sync rake task.

As you can see in the service initializer, the actual value of the API key token is expected to live in an environment variable named TRANSLATION_IO_API_KEY, and if you don't want to to include that in your shell initialization files you can invoke the rake task this way:

TRANSLATION_IO_API_KEY=<api_key_token> bin/rake translation:sync

Do you have access to the Translation.io project usage instructions? The API key token value is listed there.

Anyway, there's no problem translating some (or all) of the strings locally if you prefer. You can definitely use msgfmt from the command line, but perhaps a more convenient option would be to use a GUI based app, like Poedit.

On the other hand, making any message customizable per deployment is the way we approached this whole i18n thing. We've tested three different roads, but we're still trying to decide which one would be the best one:

Create a fork/branch per each deployment and use a custom derived locale (e.g. 'el-thessaloniki') In this way there are different variations of the same locale (e.g. 'el' would be the standard Greek translation and 'el-thessaloniki' will be the deployment specific translation for Thessaloniki). The deployment specific file doesn't need to include all the strings, only those that differ from the standard one, because if any translation is missing in the deployment specific file Rails will fallback automatically to the standard one. This approach allows us to use the Translation.io sync services with just one project without a problem, as it will process each locale independently.
Create a fork/branch per each deployment and overwrite the main locale files In this way we only keep one file per locale, but we must edit the file locally, without using Translation.io sync services (because it would overwrite the global translations), or create a new Translation.io project with a different API key.
Use a theme-based approach, where the custom themes live in their own repository This way is similar to the previous one in that we must edit the files locally or use a different Translation.io project, but we keep them in a separate repository with the rest of the files related to the specific customizations and treat them like a theme of sorts, using the custom values to overwrite the standard ones.

skarampatakis commented 7 years ago

Thank you @esebastian for your prompt reply.

I don't have access on the usage file, I get a 404. So I do not have the API key token needed, so I cannot invoke the translation:sync command.

I like the first method proposed. We already use a fork/branch per deployment approach, to customize the theme, so I think this would be the way to go for now. I will give a try to Poedit, thx for the tip!

However I think I would prefer the third method mixed with the first, since the developer would have to edit only some of the code to customize the theme and some messages. The rest of the code remains the same. So as long your master branch locales is updated with the translation.io infra, all users will have the base locales updated all times, without the need for API keys. Then you have to edit only your case specific messages and theme and you don't mess with the rest of the code.

We have done something similar with deploying GeoNode instance for the Municipality of Thessaloniki. The base code is always in sync with the master repo. We had to create only a let-name-it "theme" repo where we could define our customizations. Then Ansible takes care of the rest.

skarampatakis commented 7 years ago

@esebastian I have made some tests. I don't know if I got it correctly with what you suggested on the first method.

I set up config/application.rb as following

I18n.available_locales = [:en, :es, :el, :de, :fr, :el_thessaloniki]
    I18n.default_locale = :el_thessaloniki
    config.i18n.fallbacks = [:el, :en]

Then I created another folder config/locales/gettext/el_thessaloniki which was a simple copy of el.

Then I edited a message, saved the file and run msgfmt -o LC_MESSAGES/app.mo app.po

Restarted the server and voila.

However I had to set the url parameter locale=el_thessaloniki (caching??) to work, which to me seems very strange.

Is the procedure I described above what you meant?

esebastian commented 7 years ago

Yes @skarampatakis, that's what I meant. This way you could keep using the Translation.io sync service. If you'd rather edit manually the local .po you could work directly on your fork/branch version of the el file.

Regarding the fact that you had to manually set the URL parameter, that's because we're keeping the locale choice in the user session and it has a higher precedence that the default one, so it will apply while there's a valid cookie for the user and no URL parameter is present. You can see how this behaviour is coded in application_controller.rb#L47:

I18n.locale = params[:locale] || session[:locale] || ENV['DEFAULT_LOCALE'] || I18n.default_locale

openbudgets / participatory-budgeting

Manually change a .po #53