Bug 968588

I'd say it is kind of undefined which translations are to be used on Tumbleweed.  SLE translations are not mandatory on Tumbleweed, thus using community translations would be fine.

Michel, can you accept the SR?

Sorry, but 'NO'.

Just talked with Coolo and Ludwig about this. We do not want to maintain different translation sets for the same codebase. We will not re-introduce a zypper-1.12.x with SLE transslations vs. one with community translations.

We will continue using a single translation set. Currently merged from SLE and community SVNs. The long term goal is to actually maintain translations per code branch and not per distribution.


I'll close this bug after having reviewed the code merging the translations sets.

Hi, 

I suggest we should seek advice from the representatives of the actual users like translation coordinators/forum moderators/regional community people.

Because:

1. Actually we're not talking about merging two bug-free/correct branches of translations, but merging a buggy one (SLE's) with a good one (Community's) (for Chinese, for some other languages the situation may be in a reverse way). So we need people who know English/Local language and are actual user of openSUSE/SUSE SLE Linux to judge which is more accurate. SLE's outsourced translations are done by "general" translation professionals, while it doesn't mean it's accurate, because they may be professional in grammar, but not professionals of the culture, IT special keywords, abbreviations, usage scenarios. And SLE's users are system administers who prefer to use an English system so bugs of translations are hardly to be found by them. A funny example for them is that they have translated a string in zypper "pager" to "pager machine (the old time stuff before cellphone" in Chinese.

2. Replacing the hard works of community contributors will get them feel pissed off. I think you will be unhappy if you find the work that you translate for half a year are totally gone, replacing by something you don't know where they come from and where to get them fixed, well being pushed by community users who think you didn't get your work done right. the translation is not stuff that we can just "use" or "drop". when we use them, we should give credit; when we don't, it's also our responsibility to give reasons why we don't use them. Can you tell translators and users, "well we want to maintain branches for versions, not branches for distributions, so we deleted your well-done translations and replaced them with buggy ones?", especially "well if you want to get things right again, translate SLE again". I dare not...because if so no one will contribute work to me any more since they don't know when their work will get cleared again and whether their work are respected.

3. This is not something called rapid development, translation is never one of the things that can be done rapidly. if we don't have a final merged version, just keep it as it was. being displayed "half community, half SLE" will cause much more trouble in maintenance and bugfix than being displayed totally in the "user picked" best version. Because in theory, who breaks it, who fixes it. But can you fix something in Chinese? apparently not. then we will actually force translators to do something they may not want to do (I have done my work right, why I have to do it again?)

The only thing can be done is to set up infrastructure for the merge and hope for the best that translators will review SLE/openSUSE translations and get them merged.

Or we can do the merge carefully like this:

1. prefer community version. no contributor want his/her work get lost. SLE can use community version because as I said: 
* SLE's users don't care translations that much as community users. 
* SLE's translators (the Novell Language team, or the outsourcing company) can't care (because credits are to SUSE) or won't care (because the deal was done) the translations

2. use SLE version to fill in the community version when there're no translations in community version for the strings at all.

3. still keep both in somewhere in case in the future any kind translator would like to help to review the merged source.

Marguerite

To state the current situation: 

=== The current SVN translation branches provide for zypper:

  - SLE translations for 16 languages

  - Community translations for 64 languages (incl. the 16 SLE languages)

For whatever reason (and this is a BUG I'm going to fix) only 54 languages show up in the final zypper.rpm package.


=== Both language sets are included in the zypper source tarball.

The decision whether SLE translations supersede community translations, or not, is currently made at buildtime. So even if we use the same zypper sources in multiple distributions, we can have different policies. We had this in the past (openSUSE before LEAP).



Personally I don't prefer either set, so I leave it to the product owner to decide how it should look like. 
But I second Marguerite when she says that 'no contributor want his/her work get lost'.


If we can't reach a consensus on this, we can also head for the 'developers solution' 
and make the translation set configurable at runtime. Then everybody can use his own set.

(In reply to Michael Andres from comment #4)
> For whatever reason only 54 languages show up in the final zypper.rpm package.

JFYI: The missing 10 are sorted out by the build service %{find_lang} macro;
      Afrikaans(af) Bosnian(bs) Welsh(cy) Georgian(ka) Kurdish(ku) Lao(lo) 
      Sinhala(si) Tajik(tg) Xhosa(xh) Zulu(zu)

How do I report a bug for SUSE Linux?

Since Leap's current translation is from SLE, if I want a quick fix in translation, I should report a bug against SLE11SP1, or those "vendor updates" will overwrite my fix again and again.  But there's no such product on bugzilla.{novell.com|suse.com|opensuse.org}, does SLE use a similar thing?

Actually I found this bug is serious...today when I zypper on an just updated openSUSE server, I got a prompt for a Chinese "yes", which is not possible. So I have to msgunfmt/msgfmt the zypper.mo to workaround it. I think normal users will switch to an English locale and think SLE is stupid. Because there's no way to input Chinese there.

Every prompt in SLE is like this (unless the developers didn't allow translation for prompt):

msgid "y/n"
msgstr "y/n" <- previously "是/否"

msgid "y/n/p/v/a/r/m/d/g"
msgstr "y/n/p/v/a/r/m/d/g" <- previously the "g" was translated to "显示在寻呼机中" (show in pager)，寻呼机 in Chinese means "pager machine", "a telecommunications device similar to a beeper, SMS client, or email appliance", not "a computer program used to view the contents of a text file". I think zypper didn't have such advanced feature that some prompt will be sent to you via SMS/Email.

Marguerite

(In reply to Marguerite Su from comment #6)
> How do I report a bug for SUSE Linux?
> 
> Since Leap's current translation is from SLE, if I want a quick fix in
> translation, I should report a bug against SLE11SP1, or those "vendor
> updates" will overwrite my fix again and again.  But there's no such product
> on bugzilla.{novell.com|suse.com|opensuse.org}, does SLE use a similar thing?

You are right, unless you are registered as partner or SLE beta tester you
cannot file bugs for SLE. So the approach here is to file the bug
for Leap which shares the problem :-) Karl or someone else with
access to SLE bugs will make sure to reassign or forward the bug to
the right person then.

Closing this as the zypp part seems to be done so far. The .po files, as they are currently distributed in the libzypp/zypper package, have been moved into the source code git repo and will in the future be maintained via Weblate from here:

> https://l10n.opensuse.org/projects/libzypp/master/
> https://l10n.opensuse.org/projects/zypper/master/

The projects will be open for editing as soon as their setup is complete.


AFAIK the currently hidden openSUSE translations will be submitted as suggestions to the weblate projects, in order to review and merge them. For details about the process please ask Karl(?).