openSUSE Release Process

maybe some github webhook could be used to automatically update the pot files whenever any of the yast modules gets new commits

any update on this one? yast translations are completely separate still so shouldn't be an issue with locking etc, right?

yast translations are completely separate packages though, right? So SLE could keep using the old mechanism while opensuse moves to weblate

lnussel wrote:

yast translations are completely separate packages though, right? So SLE could keep using the old mechanism while opensuse moves to weblate

Unfortunately not. YaST in Tumbleweed and SLE12 SP2 come from the same code base. Just translations are different. Maybe they will branch in a late stage of development.

(It could be different in SLE12 SP3.)

sbrabec wrote:

lnussel wrote:

yast translations are completely separate packages though, right? So SLE could keep using the old mechanism while opensuse moves to weblate

Unfortunately not. YaST in Tumbleweed and SLE12 SP2 come from the same code base. Just translations are different. Maybe they will branch in a late stage of development.

Exactly. So for SLE yast2-trans can keep coming from svn using the old scripts and for Leap/TW we can switch to git already without hurting sle, right?

lnussel wrote:

Exactly. So for SLE yast2-trans can keep coming from svn using the old scripts and for Leap/TW we can switch to git already without hurting sle, right?

Well, yes, we can switch.

But it is better to wait until features above will be done, because:

• Without API features, manual maintenance would be problematic (hours of clicking).

• SLE translation merge could not start, as it would spam users with ~1 million e-mails, and git logs with hundreds of thousands entries.

sbrabec wrote:

lnussel wrote:

Exactly. So for SLE yast2-trans can keep coming from svn using the old scripts and for Leap/TW we can switch to git already without hurting sle, right?

Well, yes, we can switch.

But it is better to wait until features above will be done, because:

• Without API features, manual maintenance would be problematic (hours of clicking).

You lost me here. What kind of maintenance do you mean? Shouldn't it
be sufficient to import the pot and po files from svn like we did
for e.g. slideshow?

• SLE translation merge could not start, as it would spam users with ~1 million e-mails, and git logs with hundreds of thousands entries.

Maybe notifications could be turned off if that's an automated batch
operation.
Where would the hundreds of thousands of commits come from? Wouldn't
the merge be a one-shot operation? Ie one commit in each language?

lnussel wrote:

You lost me here. What kind of maintenance do you mean? Shouldn't it
be sufficient to import the pot and po files from svn like we did
for e.g. slideshow?

Even creating 50+ nearly equal tasks is a boring work.

Maybe notifications could be turned off if that's an automated batch
operation.

Not sure whether ignored subscriptions are implemented.

Where would the hundreds of thousands of commits come from? Wouldn't
the merge be a one-shot operation? Ie one commit in each language?

Not in case, where one suggestion is accepted and another edited.

sbrabec wrote:

lnussel wrote:

You lost me here. What kind of maintenance do you mean? Shouldn't it
be sufficient to import the pot and po files from svn like we did
for e.g. slideshow?

Even creating 50+ nearly equal tasks is a boring work.

Could all pot files be put into one git repo?

Maybe notifications could be turned off if that's an automated batch
operation.

Not sure whether ignored subscriptions are implemented.

If in doubt shut down the mail system on the machine and delete the
send queue :-)

Where would the hundreds of thousands of commits come from? Wouldn't
the merge be a one-shot operation? Ie one commit in each language?

Not in case, where one suggestion is accepted and another edited.

How would that be avoided if we do the switch later?

I fear that keeping yast in svn for openSUSE is just confusing.

lnussel wrote:

sbrabec wrote:

lnussel wrote:

You lost me here. What kind of maintenance do you mean? Shouldn't it
be sufficient to import the pot and po files from svn like we did
for e.g. slideshow?

Even creating 50+ nearly equal tasks is a boring work.

Could all pot files be put into one git repo?

Yes, but it only changes contents of the clicking task, not the amount.

Maybe notifications could be turned off if that's an automated batch
operation.

Not sure whether ignored subscriptions are implemented.

If in doubt shut down the mail system on the machine and delete the
send queue :-)

Yes, and then compose notification mails manually.

Where would the hundreds of thousands of commits come from? Wouldn't
the merge be a one-shot operation? Ie one commit in each language?

Not in case, where one suggestion is accepted and another edited.

How would that be avoided if we do the switch later?

Improve a commit code. Either reorder changes before commit, or ignore authorship for suggestions commits.

I fear that keeping yast in svn for openSUSE is just confusing.

I hope that the problems above will be addressed ASAP.

Stanislav, do you have an update for us? Can we get someething util beta1?

The YaST team Scrum card for this is https://trello.com/c/QHneOJGp (currently in the team backlog).

I have created an empty repo https://github.com/yast/yast-translations and gave lnussel, sbrabec and tchvatal Admin access (you may want to drop your privilege level once the setup is stabilized).

Large amount of work was just finished:

1) Strings from the community were addded to the Weblate.

2) In case of incomplete community translation, string from contracted enterprise translators were added to the Weblate. (Review can be found at ftp://ftp.suse.com/pub/people/sbrabec/yast-translations-sle-contributions/ ).

3) Conflicting strings from contracted enterprise translators were added as suggestions with suggesting user "SLE Merge Robot". Please review and pick the best from both. Feel free to review, accept, delete, edit.

4) Community translations of yast-journalctl translations disappeared from the community branch, but they survived in the enterprise branch. They were resurrected and imported instead of empty translations in the current trunk.

5) Some translations had incorrect plural form (mostly "always use singular form"). It was fixed where it was required, however it will probably appear in the Git later, after the first edit in the Weblate. (It is possible to make mass fix.)

So with yast translations for openSUSE in git and weblate how far are we? Which ones of the checkmark items are still needed?

What's missing still?

I am not sure whether Jenkins task for auto-import pot changes is already in place. If yes, we can close.

And whether auto-submit to Factory is in place.

From the Weblate side, everything is in place.

All other issues in the checklist are not YaST specific.

sbrabec wrote:

I am not sure whether Jenkins task for auto-import pot changes is already in place. If yes, we can close.

Who knows that? Jiri told me to talk to you

And whether auto-submit to Factory is in place.

Who would be in charge of that?

From the Weblate side, everything is in place.

All other issues in the checklist are not YaST specific.

If they are not needed for YaST can we track them elsewhere then?

sbrabec wrote:

I am not sure whether Jenkins task for auto-import pot changes is already in place. If yes, we can close.

Who knows that? Jiri told me to talk to you

Christopher Hofmann (cwh) was working on that.

Hi,

Am 05.01.2017 um 16:55 schrieb Stanislav Brabec:

Dne 5.1.2017 v 16:51 redmine@opensuse.org napsal(a):

[openSUSE Tracker]
Issue #11682 has been updated by lnussel.

sbrabec wrote:

I am not sure whether Jenkins task for auto-import pot changes is
already in place. If yes, we can close.

Who knows that? Jiri told me to talk to you

Christopher Hofmann cwh@suse.de was working on that.

This is already up and running since ~November.
https://ci.suse.de/job/yast-POT-updater/

Christopher¶

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

so, can we close this?