I can't find the ML-entry belonging to this issue (cc'ed Markus N).
best regards
Helmut
___________________________________________________________
Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.web.de
it's referring to the parameter options not module keywords...
Probably we should split descriptions option into two parts - keys
which are not translated and labels which can be translated.
it's referring to the parameter options not module keywords...
Probably we should split descriptions option into two parts - keys
which are not translated and labels which can be translated.
Yes, that would be highly recommended.
As it currently is (see URL above) it is not obvious that the word(s) before
the semicolon do/esn't have to be translated (causing a parser error).
I found this in four languages but did not check all translations for similar
troubles.
it's referring to the parameter options not module keywords...
Probably we should split descriptions option into two parts - keys
which are not translated and labels which can be translated.
Yes, that would be highly recommended.
As it currently is (see URL above) it is not obvious that the word(s) before
the semicolon do/esn't have to be translated (causing a parser error).
I found this in four languages but did not check all translations for similar
troubles.
OK - so translating keywords in grasslibs_*.po is ok, just watch out what one is doing in grassmods_*.po for now - right?
@Markus: thanks for merging to grass65 and trunk. Is there some easy way to do it?
Forgot to mention that I
1. update the po file(s) in 6.4
2. copy the updated files from 6.4 into my HOME
3. go into grass65svn/locale/po/
4. run the script
5. go into grass7svn/locale/po/
6. run the script
Sometimes I open the po files then in 6.5 and 7 to remove
clutter at file bottom.
a candidate for grass-addons/tools ?
Generally "why not" but it may need more error testing.
Forgot to mention that I
1. update the po file(s) in 6.4
2. copy the updated files from 6.4 into my HOME
3. go into grass65svn/locale/po/
4. run the script
5. go into grass7svn/locale/po/
6. run the script
Thanks. I will be looking into this hopefully during the weekend.
Forgot to mention that I
1. update the po file(s) in 6.4
2. copy the updated files from 6.4 into my HOME
3. go into grass65svn/locale/po/
4. run the script
5. go into grass7svn/locale/po/
6. run the script
Thanks. I will be looking into this hopefully during the weekend.
Done now. There is some effect on line breaks I'm not sure what to think about. Example below (I hope formatting will be preserved when you read this):
E.g. Milena sends me a grasswxpy_pl.po which contains:
#: ../gui/wxpython/gui_modules/dbm.py:1629
#, python-format
msgid "Unable to rename column. Column <%(column)s> doesn't exist in the table <%(table)s>."
msgstr "Nie można zmienić nazwy kolumny. Kolumna <%(column)s> nie istnieje w tabeli <%(table)s>."
the file in SVN contains:
#: ../gui/wxpython/gui_modules/dbm.py:1629
#, python-format
msgid ""
"Unable to rename column. Column <%(column)s> doesn't exist in the table <%"
"(table)s>."
msgstr ""
"Nie można zmienić nazwy kolumny. Kolumna <%(column)s> nie istnieje w tabeli <"
"%(table)s>."
po_merge.sh result:
#: ../gui/wxpython/gui_modules/dbm.py:1629
#, python-format
msgid ""
"Unable to rename column. Column <%(column)s> doesn't exist in the table <"
"%(table)s>."
msgstr ""
"Nie można zmienić nazwy kolumny. Kolumna <%(column)s> nie istnieje w tabeli <"
"%(table)s>."
See the little line break position change in the merge result for the original message? Is that OK?
On Mon, Feb 7, 2011 at 11:25 PM, Maciej Sieczka <msieczka@sieczka.org> wrote:
...
Done now. There is some effect on line breaks I'm not sure what to think
about. Example below (I hope formatting will be preserved when you read
this):
E.g. Milena sends me a grasswxpy_pl.po which contains:
#: ../gui/wxpython/gui_modules/dbm.py:1629
#, python-format
msgid "Unable to rename column. Column <%(column)s> doesn't exist in the
table <%(table)s>."
msgstr "Nie można zmienić nazwy kolumny. Kolumna <%(column)s> nie istnieje
w tabeli <%(table)s>."
the file in SVN contains:
#: ../gui/wxpython/gui_modules/dbm.py:1629
#, python-format
msgid ""
"Unable to rename column. Column <%(column)s> doesn't exist in the table
<%"
"(table)s>."
msgstr ""
"Nie można zmienić nazwy kolumny. Kolumna <%(column)s> nie istnieje w
tabeli <"
"%(table)s>."
po_merge.sh result:
#: ../gui/wxpython/gui_modules/dbm.py:1629
#, python-format
msgid ""
"Unable to rename column. Column <%(column)s> doesn't exist in the table
<"
"%(table)s>."
msgstr ""
"Nie można zmienić nazwy kolumny. Kolumna <%(column)s> nie istnieje w
tabeli <"
"%(table)s>."
See the little line break position change in the merge result for the
original message? Is that OK?
I think yes.
Also transifex (GRASS currently no longer present there after their
major site changes)
had yet different line breaks. So I don't think that this matters.
On Mon, Feb 7, 2011 at 11:25 PM, Maciej Sieczka<msieczka@sieczka.org>
wrote:
...
See the little line break position change in the merge result for
the original message? Is that OK?
I think yes. Also transifex (GRASS currently no longer present there
after their major site changes) had yet different line breaks. So I
don't think that this matters.
Indeed. I have tried braking the line in msgid's and msgstr's at
various positions. It shows that for the translation not to break, a
line break is required at '\n' only.
I find it easier to edit a po file when a single message is 1 line
rather than 2 or 3, and when the number of lines in msgid matches the
number of lines in msgstr. It also helps (me, at least) when comparing
and merging po files from different branches and sources visualy (e.g.
with meld).
For a test I have formatted graslibs_pl.po in 6.4 to use as little line
breaks as possible (although empty '""' msgid's and msgstr's are just a
clutter, there's no point in removing them too, because they would
re-appear after next msgmerge, even with --no-wrap, anyway). Are there
any objections if I do the same for remaining *_pl.po files?
@Markus: May I also suggest using msgmerge in po_merge.sh with
--no-wrap, if that doesn't pose problems I'm not aware of?
2011/2/8 Maciej Sieczka <msieczka@sieczka.org>:
...
I find it easier to edit a po file when a single message is 1 line
rather than 2 or 3, and when the number of lines in msgid matches the
number of lines in msgstr. It also helps (me, at least) when comparing
and merging po files from different branches and sources visualy (e.g.
with meld).
For a test I have formatted graslibs_pl.po in 6.4 to use as little line
breaks as possible (although empty '""' msgid's and msgstr's are just a
clutter, there's no point in removing them too, because they would
re-appear after next msgmerge, even with --no-wrap, anyway). Are there
any objections if I do the same for remaining *_pl.po files?
@Markus: May I also suggest using msgmerge in po_merge.sh with
--no-wrap, if that doesn't pose problems I'm not aware of?
Sure, we can use --no-wrap always if that helps (and works)!