Description of problem: There exist multiple placeholders in some strings of anaconda.po. They can't be rearranged in the translation. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. open the PO file using Poedit or other translation tools 2. translate the string with multiple placeholders Actual results: This makes the placeholders order in translation wrong. Expected results: The placeholders within one string should be named, so that they can be well reordered in translation. Additional info: [1] http://lists.fedoraproject.org/pipermail/trans/2010-September/008040.html [2] http://live.gnome.org/GnomeI18nDeveloperTips (search python)
Which line numbers in anaconda.pot in particular are wrong?
3545 "The %s disc was not found in any of your CDROM drives. Please insert the %s " 3546 "disc and press %s to retry." line 3545-3546 3829 msgid "Welcome to %s for %s" line 3829 3834 msgid "Welcome to %s for %s - Rescue Mode" line 3834 4742 msgid "Creating %s filesystem on %s" 4828 msgid "Creating %s on %s"
Created attachment 449012 [details] add placeholders Is something like this what you had in mind? I'm less sure on the parts in loader/, because I've never had to add these sorts of annotations to C files before.
Yes, the placeholders should be like this: "Creating %(type)s on %(device)s") Names should be added to them. It doesn't need to do this in C files. I tried to use %1$s and %2$s to distinguish them in msgstr line. But it doesn't work, and the error message was: fatal error 'msgstr' is not a valid Python format string, unlike 'msgid'. Reason: In the directive number 1, the character '$' is not a valid conversion specifier. I don't have coding experience and am not a developer, so I just supposed the file is a Python file according to the error message above:) The python file needs these names( like %(type)s ) to be added to the multi placeholders that exist in one line.
We certainly don't want this to be fixed in Fedora 14, as it would mean breaking a string freeze. Would be nice to fix it in a master branch though.
> We certainly don't want this to be fixed in Fedora 14, as it would mean > breaking a string freeze. Would be nice to fix it in a master branch though. This bug isn't marked as F14Blocker, so I was only going to commit it to master.
> Yes, the placeholders should be like this: "Creating %(type)s on %(device)s") > Names should be added to them. > > It doesn't need to do this in C files. I can do the python parts, but that's only going to clear up the last two in your list above. I'm not sure what we can do about the first three.
POT file in git contains proper placeholders, so I'm closing this bug.
I know that anaconda team is very busy now. But I have to reopen this bug. After the anaconda master po file for Fedora 18 updated, there comes a string with 3 placeholders in it. Here it is: %s may not have enough space for grub2 to embed core.img when using the %s filesystem on %s According to the details from transifex.net, the string is at pyanaconda/bootloader.py:1585 As a translator, I can't keep the placeholders' original order in the translation. That means the translation won't be right or even misleading because the placeholders will be interpreted in their original order. So I added 1$ 2$ 3$ into the %s to make sure what the order is in the translation. The translation is: 当在 %3$s 上使用 %2$s 文件系统时，%1$s 的空间大小可能无法让 grub2 嵌入 core.img I am not sure whether this is helpful. If it fails, please consider to use some name variables to distinguish these %s.
Would something like this be easier? msg = _("%(device)s may not have enough space for grub2 to embed " "core.img when using the %(format)s filesystem on %(type)s") \ % msg_dict
(In reply to comment #10) > Would something like this be easier? > > msg = _("%(device)s may not have enough space for grub2 to embed " > "core.img when using the %(format)s filesystem on %(type)s") \ > % msg_dict Yes, this will be nice.
I pushed a quick fix during last night's build of anaconda-18.29-1, removing the $ from the change in comment 9 (it was complaining about $ not being a valid specifier). If that works ok I think we'll leave it like that for f18 since we're supposed to be in string freeze.
(In reply to comment #12) > I pushed a quick fix during last night's build of anaconda-18.29-1, removing > the $ from the change in comment 9 (it was complaining about $ not being a > valid specifier). If that works ok I think we'll leave it like that for f18 > since we're supposed to be in string freeze. I see your change. How can we know whether it works?
Good question. That string isn't easy to reproduce. I am not sure exactly how the translation system handles these things. I'll look into it.
String ID: This Software RAID array is missing %d of %d member partitions. You can remove it or select a different device. String ID: This LVM Volume Group is missing %d of %d physical volumes. You can remove it or select a different device. This %s device is missing %d of %d %s. You can remove it or select a different device. There are two or more placeholders in each of these newly updated strings, but no names for them. I really can't keep them in the right order in the translation. Please, please add names to these placeholders if the strings are not freeze. For example %(partition)d, %(device)d ...
Those changes were introduced by 876441, could you add a note to that bug?
(In reply to comment #16) > Those changes were introduced by 876441, could you add a note to that bug? Added
(In reply to comment #16) > Those changes were introduced by 876441, could you add a note to that bug? I closed bug 876441 because the crash was fixed. Can we resolve the i18n deficiencies here?
Well, then we should open a new bug, not reuse an old one.
(In reply to comment #19) > Well, then we should open a new bug, not reuse an old one. Do you mean to open a new bug for this?
(In reply to comment #20) > (In reply to comment #19) > > Well, then we should open a new bug, not reuse an old one. > Do you mean to open a new bug for this? Please see the new bug https://bugzilla.redhat.com/show_bug.cgi?id=890157