Language addition on transifex

Hi,
Thanks. I see ka directory is there now.
But if you take a look on ka/katello.po (Fixes #35782 - Add Georgian translations in Katello by chris1984 · Pull Request #10365 · Katello/katello · GitHub), it’s empty.

Hi,

I am seeing it populated:

By empty I mean it’s just a template, without any translations in it.

Oh now I see

I added it to the zanata.xml file and stuff and did what @ekohl suggested. I will try to figure out what else is needed before GA

That’s why I deleted my post :slight_smile: It’s not hosted on zanata anymore, it’s on transifex. Should be some script magic I guess.

1 Like

Last week I spent time on the general problem of pulling translations into plugins:

I automated the pulling in of new translations:

https://github.com/theforeman/foreman_plugin_template/pull/38

The trick is to pull in new translations (run tx pull --minimum-perc 50 --all in the plugin) before you pull from Transifex (run make -C locale tx-pull in the plugin). Then you extract strings (run rake plugin:gettext[$PLUGIN] in foreman) and build the files (run make -C locale mo-files in the plugin).

1 Like

@NorwayFun

Katello 4.7.0 GA which is being built today and handed off to the release team, has translations in it finally :slight_smile:

1 Like

Hi,
I’ve waited for another 3 weeks and updated my Katello/Foreman nightly only today.
Katello version I got is 4.8.0-0.1.pre.master.20221222225014git53b2a56.el8
However, Katello is still in English.
Was it only GA which got translation files or is there anything I have to know?

I am just getting back from being out for the holiday. I will add this to our sprint board and follow up shortly and see what went wrong.

1 Like

Any news, please?

Hi,

Starting to work on Katello 4.7.1 and will also make a translations PR to Katello master, so we can get the translations both in nightly so it carries over into Katello 4.8 and what was missing in 4.7.1

Hello,
Just saw 4.7.1 released, so went ahead and updated my nightly too. Version I got is: 4.8.0-0.1.pre.master.20230116175840git3ef7613.el8
Did update, reboot and…


It’s still in English.

I think the problem is that we’re not compiling the .po file to .mo: I only see locale/ka/katello.po but not any locale/ka/LC_MESSAGES/katello.mo file. Not for any language. I also don’t see a task in RPM packaging to generate those.

I also looked at the various other Katello releases and none of the Katello 4.5, 4.6 or 4.7 RPMs contain any .mo files.

This is something I noticed in more plugins: we don’t have a task to generate the .mo files so many store them in git. However, generated files do not belong in version control. This is something we should add to packaging. I already created Bug #35789: Compile plugin .mo files during package build - Packaging - Foreman a while back, but this is really needed.

1 Like

Amazing find!
I compiled it manually and put it in LC_MESSAGES folder, reboot and…

Only 2 strings are in English, so I went ahead and grepped for other .po files. seems like there are 2 more:
/usr/share/gems/gems/katello-4.8.0.pre.master/engines/bastion_katello/app/assets/javascripts/bastion_katello/i18n/locale/ka.po
this, which I also recompiled and put it both with .po file and in LC_MESSAGES dir and
/usr/share/gems/gems/katello-4.8.0.pre.master/engines/bastion/app/assets/javascripts/bastion/i18n/locale/ directory,
Which has no ka.po in. Should it be pulled separately?

ops. Unfortunately, on screenshot there is foreman only which had Georgian even before.
I can provide katello screenshot with still English strings, if needed.
Sorry for inconvinience.

It’s actually been my pain point for the releases: getting everything properly translated. As you can see, even if there are translated strings it’s really crucial to get them into releases. That process is broken in a few places. This post it partly a brain dump of what I’m currently trying to fix.

So I came up with a script that uses pofilter to verify:

You can see I hardcoded a few languages, but changing that to just ka should help you decide on what needs work.

First a bit of background about the steps:

  1. Developer extracts strings: update locale/$DOMAIN.pot so Transifex can pick up the new strings
  2. Translators translate strings into each language
  3. Developer pulls in updated translations
  4. Developer releases new version
  5. New version is packaged

So for every plugin (and Foreman itself) we need to do these steps. In State of translations - 3.5 you can see I did steps 1 and 3 for the plugins (using a script), but because they were at the same time there may not have been time for step 2. It may also be that step 4 hasn’t happened yet. For some the step 3 PRs are still open.

All in all this is a rabbit hole that’s deeper than I expected, but I still intend to find my way out.

1 Like

We got more Georgian strings translated in Katello 4.7.1 so I am going to do the same on Master/nightly today as we prepare for Katello 4.8

1 Like

Thanks for all the info. Will be testing it every now and then.
Just out of curiousity, is it me or releases happen more often then nightlies are compiled?
I’ve installed it just to have latest translations available (thought it’s done automatically, when package is being built) and I see releases more often.

1 Like

There can certainly be more releases than nightly composes.

How it works is that for nightly packages we have: source release-> package release. So katello-master-source-release [Jenkins] will trigger after anything is merged to Katello’s git master branch (with some delay, so you don’t build twice if you merge multiple times within a few minutes). This then triggers katello-master-source-release [Jenkins] which actually builds the RPM.

This is then done for all packages with nightly releases. For all non-nightly packages it’s whatever is merged to GitHub - theforeman/foreman-packaging at rpm/develop that gets build using foreman-packaging-rpm-nightly-release [Jenkins].

Then once every day we run foreman-nightly-rpm-pipeline [Jenkins] (or more if we trigger it manually) which takes all the latest package versions and runs some automated tests on them. If they pass, the foreman repository is published (Index of /releases/nightly) and the katello pipeline triggered. That does the same thing using katello-nightly-rpm-pipeline [Jenkins] and Index of /katello/nightly.

That is is in a very brief overview how we manage our nightly builds. I also linked to RPMs, but for Debian packages it’s all very similar.

2 Likes

Hello,
Any news, please? :slight_smile: