Hello Neil, On Mon, May 21, 2007 at 07:12:10PM +0100, Neil Williams wrote: > On Mon, 21 May 2007 17:57:19 +0200 > Helge Kreutzmann <[EMAIL PROTECTED]> wrote: > > This is an unfounded claim. I *never* change the original strings, it > > would not even make sense, as then the translation would be ingored. > > OK, misinterpreted. I meant: please stick to structure of the msgid > strings from the POT file when creating the msgstr strings in the po.
As long as German grammar rules are followed, yes. > It seemed to me, when reading #425306 and #425307, that you had already > carried these changes through to the de.po file in #425306. That is why > I remove the 'patch' tag. Only one translated string was affected in > this way, the commas in the line describing the four commands. I suggest that you take a moment to have a look at Debian BTS documentation, specially [1] for the meaning of the tags, and [2] for the rules for closing bugs. But I will not engage in BTS ping pong. > I would like an updated de.po file - for a different reason that crops > up from reading the file and comparing with other translations: Line > lengths. <snip> > that messages are split at spaces, not in the middle of a word. Where > the error messages in the msgid strings are all on one long line, the > intention is that the program performs the wrapping at runtime and > extra newlines in the translation may cause very odd output. Please file a bug against gettext. The description you give is exactly how gettext works. The "presentation" in the po files is independent of the presentation in the programms, i.e. "foo " "bar" will be handled exactly like "foo bar" If you want to force line breaks "\n" can be used. To be sure that I did not misread the documentation, I asked on debian-i18n: http://lists.debian.org/debian-i18n/2007/05/msg00082.html I suggest that you discuss this issue there. Having sensible line breaks in po files is quite important for translators, e.g. during reviews (a diff is line based, so having lines <= 80 characters eases the process of spotting suggested changes). Similarly for other tools. Hence it is often *strongly requested* to keep lines below 80 characters (e.g. on the German translators lists). > I'll investigate this issue for future releases upstream and see if > embedded newlines in the translated string can be removed but I am not > sure if this will work. In the meantime, it is probably best to retain > long lines where they are present in the msgid. This has already been > done with other translations. To work around this bug you described, you could run something similar to "msgattrib --nowrap <something>.po" in your rules file. And *please* file bugs! > Comments are not always the best solution - you can see from the > current POT file that a general programming comment has been picked up > by gettext simply because it must occur close to a translated string > and that string doesn't deserve a comment of its own. See the msgid > string for ../src/gpe-expenses.c:160 ../src/qof-main.h:432 Again, please file a bug. We all need good tools, and only "known" bugs can be fixed. > Even adding a specific comment to the file (asking translators to > ignore this gettext greediness) does not persuade gettext to drop the > previous documentation comment. :-( > > A POT file with more comments is attached. I am not sure how I should proceed here. If you only want the reformatting (which the next translator probably will remove again) you can simply run the above command. If you've updated the pot file (i.e. the contents, not the strings) please send me the newly generated po file with the "fuzzy" marks contained. I will then also take care of the results of our discussion. > (The two spaces have not been altered in this version, I'll do that for > the next release. Please feel free to correct them in the updated de.po) This won't help. If I modify *your* strings, gettext will reject the translation. So I see two options: a) I run through the existing translation and reconsider the strings we discussed. I send you the translated version. Once you are ready to release, you fix the whitespace issues and unfuzzy all translations (because translators do not copy obvious typos). b) You prepare the template as you want the for your next release and regenerate all translations, including the German one. Once done, you send me de.po and I'll unfuzzy all strings, and update those we discussed (where appropriate). After that I send the updated de.po to this bug report. > This may change in future releases - the code that creates these > strings may well be migrating to a different file in order to support > the next stage of gpe-expenses development: sharing expenses data with > other applications in real time. Greetings Helge [1] http://www.debian.org/Bugs/Developer#tags Note, however, that since most of my (suggested) changes were not correct, the removal of the "patch" flag was proper. However, this is completely independent of any other bug report (neither by me or by someone else) or the severity of the bug report. [2] http://www.debian.org/Bugs/Developer#closing Excerpt: Debian bug reports should be closed when the problem is fixed. Problems in packages can only be considered fixed once a package that includes the bug fix enters the Debian archive. -- Dr. Helge Kreutzmann [EMAIL PROTECTED] Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: Digital signature
