Mailinglist Archive: yast-devel (211 mails)

< Previous Next >
Re: [yast-devel] new translation server and YaST
On 13.10.2015 09:40, Josef Reidinger wrote:
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.

Someone still needs to run `create pot file for $this repository`, but
this can be automated quite "easily", for instance, in Jenkins.

I already have a script that can generate all pot files for all Yast
repositories at once, also considering that not all Yast repositories
need to have the "latest" branch, especially SLE 11 might have, e.g.
only `SP2` branch, and nothing "younger".

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.

Yes, but IIUC - now these translations are expected to be pushed to Yast
repositories automagically from the server, which is actually no way
from my POV. Currently, there are no pot/mo/whatever files in Yast repos.

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.

Agree

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.

+1 but Code Review process is currently mandatory for ALL YAST REPOS.

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.

And I would like this to keep the same. But what would be actually
acceptable (for me) is to create ${yast_module}-translation repository
anywhere at GitHub (be it under SUSE/openSUSE/yast) for every single
Yast repository ... or even one repository yast-translations.

We would then grant RW access to your auto-user to this/these repo(s)
and we could automagically update pot files generated from code.

Steps that need to be done on import to Weblate:

3. These translations will be pushed to GitHub (one shot).

You might want to keep the history, in this case, my team might still
have some tools for SVN2GIT conversion...

5. opensuse-i18n robot will be allowed to push to your project (not
needed in case of pull requests)

Yes, if we talk about a special repository for translations with special
rules: no review needed.

Thanks for taking care and also for contacting the team in advance
Lukas

--

Lukas Ocilka, Systems Management (Yast) Team Leader
SLE Department, SUSE Linux
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >