Bug 116449

post 10.0 issue

re-opening for checking.

Another goal is to prevent customers and testers from files bug about "missing" translations.  Testers must know in advance which text should stay untranslated.  A straight forward way would be to color these texts pink during the beta test cycle.

Stano, do you understand what I mean?  Can you help with these problems?

Stefan, any comment?

What texts are you referring to?

There are at least three categories:

1. Termini like "requires" (RPM related) or certificate stuff.

2. Security settings derived from filenames ("easy", "paranoid").

3. Output issued by programs like SuSEconfig.

I'm afraid we have only two ways for YaST texts:

1. Add proper comments saying "don't translate XXX"

2. Inserting texts not to be translated via sformat (_("... %1 ..."), "XXX)

Possibility 2 is safer (translators have simply no way to translate the text), however, it might prevent them from having the translation gramatically correct (I personally have no experience, but even the word "Linux" has several forms in some languages, and if we don't allow translators to use appropriate form, the sentence sounds worse then).

Anyway, we probably have to solve it on per-case basis, there is no way to solve this issue in general.

Coloring texts during beta phase (or inserting them into other tag) would help only for the help texts - but there is no way to do it for all widgets in general :-( (Stefan, please, check whether it is true)

Karl, I'm resolving this one as WONTFIX even if it is an issue. If you have any idea how to solve it in general, please, reopen. Otherwise, please, file separate bug for each issue.

thanks for commenting.  it might be the best to start collecting all pathological cases, take screenshots and send them to the translators and testers (QA).  Interesting project...  I'm inclined to discuss it on the opensuse-translation mailinglist--maybe, we can find someone who is interested in documenting affected YaST dialogs.

Coloring those texts would mean changing the underlying toolkit. I don't see any reasonable way to do this.

One more idea: What about adding an additional HTML tag (or any other kind of tag) which would be removed by libyui before passing the text to widgets? Translators would get texts including this tag, user would not.

The problem I see is finding a sequence of chars as the tag, which would not break anything...

Now I'm inclined to believe we should not try to solve this at a technical level.  Some message do not even appear in the .pot files (SuSEconfig output).  I'd rather like to ask that the yast hackers send me screenshots of dialogs that *intentionally* contain "untranslated" fragments.  With the time our collection will grow and it will help the testers (QA).

No immediate action required :)

Documenting those few cases should be simple enough. 

So far, only some RPM terms come to mind: "requires", "provides", "pre-requires". Those had been translated to death in the German version so that they had been useless for experts because their original meaning had gone completely lost (there is hardly any chance to make a distinction between "requires" and "pre-requires"), and novice users can't make any sense of it one way or the other anyway.

(In reply to comment #10)
> One more idea: What about adding an additional HTML tag (or any other kind 
> of tag) which would be removed by libyui before passing the text to widgets?
> Translators would get texts including this tag, user would not.

For one thing, those strings are not HTML to begin with. They are pure QStrings in pure C++ code. To mark them for translation would mean to pipe them into the gettext mechanism while making sure the string remains the same.

IIRC KDE uses a CPP macro K18N_NOOP to make strings appear in .pot files.

If you would try hard enough you could find translations that would fit.  Translating 1:1 in many cases is not possible, but approximizations are.  In the end, it is just about getting used to a translated term.  For "requires" and "pre-requires" you could try "Bedingung" and "Vorbedingung", or Erfordernis and Vorab-Erfordernis, or if you prefer something shorter: "Muß" and "Vorab-Muß".  Yes, at first all these translations sound strange, but it is possible to get used to it.

"Possible to get used to" is the thing that users don't want. This is very much like the translated messages of "make" (Yuck!), of system messages ("Der Wecker klingelt" - gaaaaaaaa!!) or "gcc" (of all things).

Some things are better left untranslated. Some translations only create confusion. In general, the more technical something gets, the more likely a translation will tend to confuse rather than be helpful: They instantly downgrade expert users to clueless newbies because they can't figure out the original meaning. Only when you know the original message well enough and translate it back (and you happen to get the right translation) you can make any sense of it. "Der Wecker klingelt" is one perfect example for such a translated-to-death message. And there are more.

Dumbing down experts to newbie level may be a democratic (or even communist) approach (leaving everybody on the same level), but it is not helpful for either the (ex-) experts or the newbies.

How about adding a para to the help text of these modules for the translated languages only that explains the untranslated term? There is no technical solution.  The best solution is to teach the translators to think a little and read the comments before complaining.  Then any bugs that get filed can be closed because they aren't bugs.

It's not about translators here.  It's about the testers who report "untranslated strings again and again (from release to release).  I do not argue that "requires" and "pre-requires" must be translated. I simply want the QA guys to see, that localization is complete even if English words or phrases appear from time to time.  As said, it would be very helpful if the hackers could provide caveat screen shots in advance.  I do not ask for those screen shots because I know that the hackers have worry about much more serious things.