Mailinglist Archive: yast-devel (211 mails)

< Previous Next >
Re: [yast-devel] new translation server and YaST
On Mon, 12 Oct 2015 22:23:39 +0200
Stanislav Brabec <sbrabec@xxxxxxxx> wrote:

We are now working on a launch of a new translation server:

We just added first few projects, but we plan to migrate all
translations there after the beta phase.


No more need for picking pot from GitHub, uploading it to LCN SVN,
waiting, picking translations back. Weblate is built on top of GIT,
and translation can be automatically uploaded to GIT. Imagine that
openSUSE LCN SVN has projects, where nobody picked translations for 7

Weblate features translation merge across branches. We can create
common translation covering both SLE and openSUSE. No more
divergences in translations.

That sounds good in general, but SLE translations is done by external
company and openSUSE ones by community, so question is if both agreed
on it. In general YaST will use whatever translators find comfortable.

The only work on developers side is (in the current version) updating
of po files against the latest pot and pushing it to the git repo.
(And even it can be automatized in future.)

This is also what we do for svn, so I do not see difference.

What will be needed before YaST can be added to Weblate:

1) Decide how YaST will manipulate with po files. Currently all po
files for all repositories reside in a single repository (and later
in a single package). It was useful in time of manual downloads and
uploads, where no -lang package merging was implemented. Now it will
complicate fully automatic work flow, as pot files needs to be
transferred across repositories (at least until somebody invents a
robot for it).

YaST just generate pot files and upload to svn. Then it is up to ke how
it is proceed further.

2) Decide how YaST will accept translations.

Standard way is an automatic pushing of translations to git using
rules defined by Weblate (currently 100% reached or no changes in
last 2 hours) by dedicated user (opensuse-i18n). I was pointed to the
problem that YaST developers may need to review some strings and edit
their test suites. I guess that there can be techniques that can help
with watching of such special changes. But in general, I think that
developers have no chance to review translations.

I do not expect that developers will review translations.

Another way is pull request (GitHub only). With pull requests,
developers will get pull request on each change mentioned above.
Pull request could possibly add a lot of work to you. Imagine, that
50 modules with 16 languages can generate nearly 1000 pull requests
in on translation round.

no way for us. We have more then 100 modules.

Third way is manual pulling from the Weblate on request. I would
avoid this as much as possible. If you update po files in GitHub, you
will get conflict, and problem would need manual git merge.

YaST team in general do not care about translations, just fixing
non-translatable strings and similar issues.

3) Have cleanly defined branch for SLE (and possibly other projects).

I guess it is already done in a such way:

yes, see

All projects, where translations are maintained in parallel for
different versions, need to have branch in the repository. Weblate
will then be able to push the correct po file to each branch.

4) Merge openSUSE and SLE translations.

openSUSE and SLE translations diverged over the time, as there is no
merging process. Translation team agreed on merge of both.

if translation team want to merge it, we are fine with it.

The merge is planned to be performed on Weblate side:

3a) GitHub will import openSUSE translations.
3b) Weblate will import SLE translations as change suggestions.
3c) Translators will be asked to perform review.
3d) The standard process will post merged translations to GitHub.

Technical details:

Steps that need to be done on import to Weblate:

1. The last import from LCN SVN trunk branch will be done.
2. po and pot files will be removed from LCN SVN trunk branch.
3. These translations will be pushed to GitHub (one shot).
4. Weblate web service (in GitHub webhooks) will be added to each
project configuration.
5. opensuse-i18n robot will be allowed to push to your project (not
needed in case of pull requests)
6. Project will be imported to
7. master branch will be added to that project
8. The last import from LCN SVN SLE branches.
9. po and pot files will be removed from LCN SVN SLE branches.
10. Particular SLE branches will be added to that project.
11. These translations will be added to Weblate as suggestions.
12. Translators will be asked for review and string merge.
13. When the merge will happen, robot will push merged translations
to GitHub.

In general I do not see problem with these steps.

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >