Description of problem:
Apparently the Hebrew translation was just using the old Mandriva translation, and hence the MCC is full of references to Mandriva.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start MCC
Screencaps of a couple places where I noticed this: http://imgur.com/mBapv,A9SHU
feel free to provide the translation here
Hebrew translation problems =>
Hebrew translation problems (drakconf)QA Contact:
As you can see here we don't have a Hebrew translation team: https://wiki.mageia.org/en/I18n_teams
Since we are not able to write Hebrew we can't fix this issue regarding Mandriva related strings (in some languages using s/Mandriva/Mageia/ would be sufficient, but not in Hebrew).
It would be great if you could provide a patch or a fixed po file for the next release of drakconf :)
I would be happy to, but there are several things preventing me:
1. I don't have a lot of time to spare for this.
2. I have very little time to spare for this.
3. There appear to be many commented out lines in the file, and in general I'm not sure what is going on there.
Ping me on IRC (Max__) so we can do this in real time.
Created attachment 2608 [details]
Proposed fixed po file
Using the Find/Replace function in Kwrite I replaced all the "Mandriva" strings with "Mageia" strings in Hebrew.
This probably needs some QA or something before being pushed.
I spot that some translations miss "%s"
And indead "msgfmt -c /dev/null he.po" complains
he.po:554: number of format specifications in 'msgid' and 'msgstr' does not match
he.po:635: number of format specifications in 'msgid' and 'msgstr' does not match
he.po:1048: number of format specifications in 'msgid' and 'msgstr' does not match
he.po:1124: number of format specifications in 'msgid' and 'msgstr' does not match
he.po:1176: number of format specifications in 'msgid' and 'msgstr' does not match
msgfmt: found 5 fatal errors
aka, you must translate "Mageia" (line 549, as "××××" ?) and keep %s in translations, not replace "%s" by "Mageia".
We need that in every line? What does the %s do anyway?
Yes, we need that in every line where the original has %s. It indicates where a string goes that is inserted at run time by the program.
Attachment 2608 is obsolete:
I got this message:
firstname.lastname@example.org <email@example.com> 5 October 2012 06:00
Reply-To: List dedicated to internationalisation issues <firstname.lastname@example.org>
Reply | Reply to all | Forward | Print | Delete | Show original
Hi, you are the assignee for the following bugs for Mageia and we would like to know whether they were assigned correctly. For each of them: * Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. * If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. * Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. * You will not be pinged for this again, if the status is set to ASSIGNED or if the whiteboard contains the string OK. Thanks a lot!
This search was scheduled by email@example.com.
Bugs that need you ID Sev Pri Plt Assignee Status Resolution Summary
6416 normal Normal All mageia-i18n NEW --- Hebrew translation problems (drakconf)
My reply was :
Sorry, cannot help you. I do not read/write Hebrew.
Why is this happening?
You received the message as it was sent by bugzilla to the i18n list.
(In reply to comment #9)
> Sorry, cannot help you. I do not read/write Hebrew.
> Why is this happening?
Romain (rda) did great reminder for us. This is just a call for volunteers.
Mailing list firstname.lastname@example.org is international so it's the only way to notify us translators as we don't have Hebrew mailing list yet.
Please don't change Assigned To: field for this bug as we're the only team we can do anything.
Thanks for your help with this bug :)
I don't understand what is happening now, you said you're very short on time. Does that mean you can't redo the fix, while keeping all instances of %s?
The actual fix while keeping the %s doesn't take long.
But I seem to have lost the source file... :\
(In reply to comment #13)
> The actual fix while keeping the %s doesn't take long.
> But I seem to have lost the source file... :\
I hope someone from i18n will explain.
Is this the newest file?
It contains a lot of ××××
However, line 549 still has:
msgstr "×× ××¨××× ××× ××§×¡"
that should become
too, I think (so without "××× ××§×¡", bacause Mageia is Mageia and not Mageia Linux)
The Mageia Linux thing can be fixed, yeah.
But I don't think that that's the right file, because some lines have %s and some don't. And I don't know where this character goes and where it doesn't. :\
Can we have a little guidance from i18n please?
%s will be replaced at run time by another string.
In most of these cases, it'll be "Mageia".
However previously, "Mandriva" was hardcoded but in Hebrew.
It should be pretty straightforward for one that can read Hebrew to replace "Mandriva" or "Mandriva Linux" in Hebrew by "%s"
OK. Now I am thoroughly confused.
Do we want the Hebrew "Mandriva" strings to be hardcoded to "Mageia" Hebrew strings, or do we want to replace all Hebrew "Mandriva" strings with %s ?
If the english string has Mageia, then the translation must have Mageia (possibly written in Hebrew).
If the english string has "%s", then the translation must have "%s" (instead of sometimes "mandriva" or "mandriva linux" written in hebrew in some bad translations).
It would be useful if you check also https://wiki.mageia.org/en/Merging_po_files_with_newer_pot_files for detailed instructions how to check your translation with msgfmt -c (see comment #5).
Created attachment 2939 [details]
proposed_he.po without needed %s
(In reply to comment #16)
> %s will be replaced at run time by another string.
> In most of these cases, it'll be "Mageia".
> However previously, "Mandriva" was hardcoded but in Hebrew.
> It should be pretty straightforward for one that can read Hebrew to replace
> "Mandriva" or "Mandriva Linux" in Hebrew by "%s"
I'm afraid it is not that easy.
It seems impossible to do that, if you add it on the good end of a string, the %s jumps to the wrong end of it. If you add it on the wrong end, it stays on the wrong end and won't jump to the good end. Is it allowed to combine a LTR with a RTL language between ""?.
In revision 6106 (where tv added Max's fix) there was one instance of Mandriva Linux ("×× ××¨××× ××× ××§×¡")left, in the attached file it is replaced by Mageia ("××××"), and there were about 10 "Mageia Linux"'s, so in the attached file "×××× ××× ××§×¡" was replaced by "××××" only.
I didn't run the check Filip proposed (sorry Filip, but the check will fail anyway, and I'm not in i18n)
I found a way to add the %s, if it should go at the end of a Hebrew string:
Using kwrite: first, type '"%s ' on the left of that string, then remove '"××××'
However, is it worth the trouble... is there any guarantee it will work?
Depending on which tool you use to look at the he.po file, you can see very weird things, for instance the first letter of a word being put at the end of it, or a string like '(%s)\n' being shown as 's)\n(%'
It is worst when using vim: the letters constantly change places if you try to edit something
Thanks for your help Marja. It seems that we should be practical and just hardcode Mageia in those strings. If Max can check if txt is OK in MCC with the new file we improved situation anyway.
Maybe someone with some experience about LTR/RTL can jump in.
It should _NOT_ be hardcoded.
And anyway nobody will be able to commit such a file (check is done prior accepting commiting).
The string "%s" will be replaced at runtime by the translation of "Mageia" which will be LTR too, thus a LTR string inserted in a LTR string at "%s" position.
This won't be a problem.
You can easily check by running the following command as root:
"msgfmt -o /usr/share/locale/he/LC_MESSAGES/drakconf.mo he.po"
Then just start mcc in order to check your translations.
Created attachment 2940 [details]
proposed he.po with %s
Replacing ××××, where needed, with %s went well with gvim (even though gvim showed the characters in the strings in reversed order)
After that I replaced ×××× in the Mandriva changelog with ×× ××¨×××, because there Mandriva should be kept, but didn't care very much about the commented out lines at the end of the file.
I didn't find time to work out how to run msgfmt -c properly. I got:
[marja@Denkblok2 Documents]$ msgfmt -c proposed_%s_he.po
where I had expected to see some messages.
* the file needs to be checked by someone who speaks Hebrew
* the msgfmt -c check still needs to be done
Feel free to do that :)
Attachment 2939 is obsolete:
(In reply to comment #24)
> I didn't find time to work out how to run msgfmt -c properly. I got:
> [marja@Denkblok2 Documents]$ msgfmt -c proposed_%s_he.po
> [marja@Denkblok2 Documents]$
> where I had expected to see some messages.
That probably means no errors :)
you can use -cv to make it more verbose...
if you still get no output, loose the %s in the filename as it might confuse msgfmt...
(In reply to comment #24)
> Created attachment 2940 [details]
> proposed he.po with %s
> * the file needs to be checked by someone who speaks Hebrew
> Feel free to do that :)
Not sure exactly what I'm looking for, but the file seems to be OK.
There are probably some LTR-RTL problems in there, at least, looking at the source text it appears that there will be, but until we actually test it there is no way to know for sure.
However, that's not much of an issue. Any Hebrew speaker using a computer is used to RTL-LTR mixups, especially when the language changes in the middle of the line. Some software is better at handling it than others.
Except for the comments and the changelg I didn't see any instance of the Hebrew word ×× ××¨××× in the file.
(In reply to comment #23)
> It should _NOT_ be hardcoded.
Thanks for clarification.
> And anyway nobody will be able to commit such a file (check is done prior
> accepting commiting).
Are you sure that precommit hooks works as they should? I'm asking as bug 6816 is not closed yet. As a consequence there are still several pot files which don't pass msgfmt -c test. I hope that someone will dive there soon. We need sysadmins and i18n members for solving this situation and thus avoiding bugs as this one in the first place.
(In reply to comment #25)
> (In reply to comment #24)
> > I didn't find time to work out how to run msgfmt -c properly. I got:
> > [marja@Denkblok2 Documents]$ msgfmt -c proposed_%s_he.po
> > [marja@Denkblok2 Documents]$
> > where I had expected to see some messages.
> That probably means no errors :)
> you can use -cv to make it more verbose...
Thanks :) Now I got:
[marja@Denkblok2 Documents]$ LC_ALL=C msgfmt -cv proposed_%s_he.po
352 translated messages, 11 fuzzy translations, 5 untranslated messages.
Is that good enough if there aren't any not translated or wrongly translated strings in MCC?
@ Max and/or Shlomi,
Could you please test the attached po file with the steps tv explained in comment 22? I wouldn't be able to notice any regressions in the translations
s/comment 22/comment 23/
(In reply to comment #28)
> (In reply to comment #25)
> > (In reply to comment #24)
> > > I didn't find time to work out how to run msgfmt -c properly. I got:
> > >
> > > [marja@Denkblok2 Documents]$ msgfmt -c proposed_%s_he.po
> > > [marja@Denkblok2 Documents]$
> > >
> > > where I had expected to see some messages.
> > That probably means no errors :)
> > you can use -cv to make it more verbose...
> Thanks :) Now I got:
> [marja@Denkblok2 Documents]$ LC_ALL=C msgfmt -cv proposed_%s_he.po
> 352 translated messages, 11 fuzzy translations, 5 untranslated messages.
> [marja@Denkblok2 Documents]$
> Is that good enough if there aren't any not translated or wrongly translated
> strings in MCC?
> @ Max and/or Shlomi,
> Could you please test the attached po file with the steps tv explained in
> comment 22? I wouldn't be able to notice any regressions in the translations
Marja said she meant comment 23 .
-- Shlomi Fish
Out of curiousness, I had a look too.
It is *worse*, now, in cauldron I see:
[Control Center [on localhost ××××
where the string was completely Hebrew before (with the hard-coded Mandriva Linux)
In the he.po file, that string is
%s ××¨×× ×××§×¨× ×©×
so I don't understand what went wrong. (btw, in Mageia 2 I've seen the same, but also the opposite: the entire string being in Hebrew, except for Mageia... maybe the opposite was caused by my not having closed MCC before taking tv's steps and starting it again.. I had 2 MCC's running at the same time)
With both the old and the proposed he.po, at least the following strings are in English instead of in Hebrew in my cauldron:
* Configure updates frequency
in the po file:
#, fuzzy, c-format
msgid "Configure updates frequency"
msgstr "××××¨×ª ,×ª××× ×ª ×©××ª××£ ××§×××¦××ª ×¢××××"
* Configure system security, permissions and audit:
#, fuzzy, c-format
msgid "Configure system security, permissions and audit"
msgstr "××× ×× ×¢××× ×©× ××¨×©×××ª ×××××× ×©× ×××¢×¨××ª"
* Configure authentication for Mageia tools
That one is really missing:
msgid "Configure authentication for Mageia tools"
* In the about screen: Mageia Contributors, Copyright (2x)
Mageia Contributors was already translated, though:
#, fuzzy, c-format
msgid "Mageia Contributors"
msgstr "×× ×©×× ×©×ª××¨××× ×× ×¢×××¨×× ×××××"
Anyway, it doesn't seem a good idea at all to commit the attached po file
Does anyone understand why the strings with %s for ×××× turn out so bad?
The "fuzzy" tag that you can see above the strings that you quoted means "I'm not sure that the translation is 100% accurate, so for now let's display the original string until a translators proofreads this." So these strings are displayed in English.
The "fuzzy" tag should be removed if we want these translations to be displayed.
(In reply to comment #27)
> Are you sure that precommit hooks works as they should? I'm asking as bug 6816
> is not closed yet. As a consequence there are still several pot files which
> don't pass msgfmt -c test. I hope that someone will dive there soon. We need
> sysadmins and i18n members for solving this situation and thus avoiding bugs as
> this one in the first place.
Oh yes they do.
When updating pos (even for just syncing with code) I got bitten back b/c some had previous errors which I'd to fix prior to being able to commit my changes (urpmi, rpmdrake, control-center, drakx, ...)
Committed latest Marja changes (http://svnweb.mageia.org/soft/control-center/trunk/po/he.po)
Note that we should add credit for Max at top of file, which he didn't, but since he uses only a first name, I'm not sure he want to publicly get credit?
(In reply to comment #32)
> The "fuzzy" tag that you can see above the strings that you quoted means "I'm
> not sure that the translation is 100% accurate, so for now let's display the
> original string until a translators proofreads this." So these strings are
> displayed in English.
Ah, thanks Akien, I was indeed wondering whether the word "fuzzy" in this place was the same as the "fuzzy tag" we had talked about before :)
(In reply to comment #34)
> Committed latest Marja changes
> Note that we should add credit for Max at top of file, which he didn't, but
> since he uses only a first name, I'm not sure he want to publicly get credit?
My changes made things worse. The words in the same string as "××××" aren't Hebrew any more, even though they were in Hebrew before my changes were made.
I checked the Arab po file, too, the problem does not exist there, in Arab not only the word that replaces %s, but the entire string is in Arab.
There must be something very wrong with the po file I made.
Created attachment 2961 [details]
Shlomi's review of fuzzy strings
Shlomi reviewed the translations of the fuzzy strings earlier today, using http://svnweb.mageia.org/soft/control-center/trunk/po/he.po?revision=6229&view=markup
So attaching his comments.
Can fuzzy in a po file also mean that the line numbers need to be checked? Or can the fuzzy tags from all strings Shlomi found to be correct, now be removed (and the same with the ones he had corrections for, after the corrections are done), without comparing line numbers with anything?
Attachment 2940 is obsolete:
The line numbers do not have any meaning besides telling from where came the string.
The translation only got fuzzed if the english string changes or if someone manually fuzzy it b/c it's broken (such as missing "%s" preventing to commit)
(In reply to comment #39)
what do you wish to know?
-- Shlomi Fish
When I will get the fixed translation?
Created attachment 3199 [details]
Hebrew translation of Control-Center a.k.a MCC
Hi guys, this is the full translation (not a diff/patch).
I checked this file several times for errors and mistakes, I hope I got them all.
Feel free to comment on this change.
That looks incomplete since translation of eg: "Mageia Contributors" has not changed whereas we replaced "Mandriva" by "Mageia" in the english string.
Anyway I commited it.
OK, in this case I must ask, are the PO files being automatically updated when the POT file is updated?
When new strings are added, I first update the pot file then the *.po files
(really just "cd po; make *pot; make merge")
For the record, I did run "make merge" on just your file prior to commiting in order to prevent ping-pong in commits due to Virtaal not respecting formating enforced by msgmerge (it splits comments such as lines numbers over multiple lines which would be reverted on next update, making SVN history less readable for no purpose).
Me thinking only emacs is good at editing po files :-)
This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.
The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.
Thank you for reporting this bug and we are sorry it could not be fixed.
The Mageia Bugsquad