mifr/subsurface
1
0
Fork 0
mirror of https://github.com/subsurface/subsurface.git synced 2024-12-01 06:30:26 +00:00
Code Issues Projects Releases Packages Wiki Activity
subsurface/po/de_DE.po

1306 lines
23 KiB
Text
Raw Normal View History

Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
# German translations for Subsurface package
# German messages for Subsurface.
# Copyright (C) 2012 Subsurface's COPYRIGHT HOLDER
# This file is distributed under the same license as the Subsurface package.
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
# Dirk Hohndel <dirk@hohndel.org>, 2012.
#
msgid ""
msgstr ""
"Project-Id-Version: 2.0.1\n"
"Report-Msgid-Bugs-To: \n"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
"POT-Creation-Date: 2012-10-21 00:50-0700\n"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
"PO-Revision-Date: 2012-10-10 16:27+0900\n"
"Last-Translator: Dirk Hohndel <dirk@hohndel.org>\n"
"Language-Team: German\n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:162
msgctxt "Stats"
msgid " > Month"
msgstr " > Monat"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1515
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid " Please select dive computer and device. "
msgstr " Bitte Tauchcomputer und Gerät auswählen. "
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:160
msgid "#"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Nr."
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: statistics.c:553 statistics.c:625 statistics.c:627 statistics.c:629
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "%.*f %s/min"
msgstr "%.*f %s/min"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#. ++GETTEXT 80 chars: lead text ("" or localized "Dive #%d - ") weekday, monthname, day, year, hour, min
#: print.c:72
#, c-format
msgid "%1$s%2$s, %3$s %4$d, %5$d %6$d:%7$02d"
msgstr "%1$s%2$s %4$d. %3$s %5$d %6$d:%7$02d"
#. ++GETTEXT 160 chars: weekday, monthname, day, year, hour, min
#: print.c:229
#, c-format
msgid "%1$s, %2$s %3$d, %4$d %5$dh%6$02d"
msgstr "%1$s %3$d. %2$s %4$d %5$dh%6$02d"
#. ++GETTEXT 60 char buffer weekday, monthname, day of month, year, hour:min
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:385
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#, c-format
msgid "%1$s, %2$s %3$d, %4$d %5$02d:%6$02d"
msgstr "%1$s %3$d. %2$s %4$d %5$02d:%6$02d"
#. ++GETTEXT 80 chars: weekday, monthname, day, year, hour, min
#: statistics.c:529
#, c-format
msgid "%1$s, %2$s %3$d, %4$d %5$2d:%6$02d"
msgstr "%1$s %3$d. %2$s %4$d %5$2d:%6$02d"
#: print.c:254 statistics.c:536
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "%d min"
msgstr "%d min"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:507
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "%dd %dh %dmin"
msgstr "%dt %dst %dmin"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:509
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "%dh %dmin"
msgstr "%dst %dmin"
#: dive.c:618
#, c-format
msgid "(%s) or (%s)"
msgstr "(%s) oder (%s)"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:851 gtk-gui.c:922
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
msgid "About Subsurface"
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:46:15 +00:00
msgstr "Info zu Subsurface"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:916
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
msgid "Add Dive..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Tauchgang hinzufügen..."
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2023
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Add dive"
msgstr "Tauchgang hinzufügen"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2102
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Add to trip above"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Zur obigen Reise hinzufügen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:46
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Apr"
msgstr "Apr"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:47
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Aug"
msgstr "Aug"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:931
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Autogroup"
msgstr "Automatisch gruppieren"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:664
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Automatically group dives in trips"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Automatisch die Tauchgänge gruppieren"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:168
msgctxt "Depth"
msgid "Average"
msgstr "Ø"
#: statistics.c:165
msgctxt "Duration"
msgid "Average"
msgstr "Ø"
#: statistics.c:171
msgctxt "SAC"
msgid "Average"
msgstr "Ø"
#: statistics.c:174
msgctxt "Temp"
msgid "Average"
msgstr "Ø"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:692 statistics.c:729
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Avg Depth"
Small adjustments to the German translation Consistently use "Ø" for average. Use Tauchgruppenleiter and Leiter instead of Tauchgruppenführer and Führer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 22:21:57 +00:00
msgstr "Ø Tiefe"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:700
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Avg SAC"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Ø AMV"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:675
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Avg Temp"
Small adjustments to the German translation Consistently use "Ø" for average. Use Tauchgruppenleiter and Leiter instead of Tauchgruppenführer and Führer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 22:21:57 +00:00
msgstr "Ø Temp"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:682
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Avg Time"
Small adjustments to the German translation Consistently use "Ø" for average. Use Tauchgruppenleiter and Leiter instead of Tauchgruppenführer and Führer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 22:21:57 +00:00
msgstr "Ø Dauer"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:592
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Bar"
msgstr "bar"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:515 info.c:942 print.c:156
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Buddy"
msgstr "Partner"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:602
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Celsius"
msgstr "Celsius"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:522
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Choose Default XML File"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Standard XML Datei auswählen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1409
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Choose XML Files To Import Into Current Data File"
msgstr ""
"Bitte XML Dateien auswählen, die in die aktuelle Datei eingefügt werden "
"sollen"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:912
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
msgid "Close"
Update German translations for newly added menu strings Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:15:08 +00:00
msgstr "Schließen"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2119
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Collapse all"
msgstr "Alle einfalten"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2092
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Create new trip above"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Neue Reise darüber einfügen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:598
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "CuFt"
msgstr "cuft"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:1269 gtk-gui.c:622
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Cyl"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Flasche"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:934 equipment.c:1070
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Cylinder"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Flasche"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1580
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Cylinders"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Flaschen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:1262 print.c:155 statistics.c:720
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Date"
msgstr "Datum"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:807
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Date and Time"
msgstr "Datum und Zeit"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:817
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Date:"
msgstr "Datum:"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:47
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dec"
msgstr "Dez"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:669
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Default XML Data File"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Standard XML Datei"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:256
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Delete"
msgstr "Löschen"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:207
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Delete Dive"
msgstr "Tauchgang löschen"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2010
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Delete dive"
msgstr "Tauchgang löschen"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2009
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Delete dives"
msgstr "Tauchgänge löschen"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:155 statistics.c:160
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Depth"
msgstr "Tiefe"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:867
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "Depth (%s):"
msgstr "Tiefe (%s):"
#: uemis.c:156
msgid "Depth Limit Exceeded"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Tiefenbegrenzung überschritten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:586
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Depth:"
msgstr "Tiefe:"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1377
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Device name"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Gerätename"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#. ++GETTEXT 80 char buffer: dive nr, weekday, month, day, year, hour, min
#: info.c:107
#, c-format
msgid "Dive #%1$d - %2$s %3$02d/%4$02d/%5$04d at %6$d:%7$02d"
msgstr "Tauchgang #%1$d - %2$s %4$02d.%3$02d.%5$04d um %6$d:%7$02d"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:159 print.c:67
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "Dive #%d - "
msgstr "Tauchgang #%d - "
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:252
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:46:15 +00:00
#, c-format
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
msgid "Dive %d: %s %d %04d"
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:46:15 +00:00
msgstr "Tauchgang Nr. %d: %s %d %04d"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1133 info.c:700 statistics.c:711
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive Info"
msgstr "Informationen"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1125
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive Notes"
msgstr "Notizen"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:721
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive Time"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Dauer"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:162
msgid "Dive Time Alert"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Alarm: Tauchgangsdauer"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:160
msgid "Dive Time Info"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Info: Tauchgangsdauer"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1346
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive computer"
msgstr "Tauchcomputer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:371
msgid "Dive data import error"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Importieren der Daten des Tauchgangs"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:476
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive details"
msgstr "Notizen zum Tauchgang"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:514
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive master"
Small adjustments to the German translation Consistently use "Ø" for average. Use Tauchgruppenleiter and Leiter instead of Tauchgruppenführer and Führer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 22:21:57 +00:00
msgstr "Tauchgruppenleiter"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:155
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dive#"
msgstr "Tauchgang Nr."
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:652
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Divelist Font"
msgstr "Schriftart für Tauchliste"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:941
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Divemaster"
Small adjustments to the German translation Consistently use "Ø" for average. Use Tauchgruppenleiter and Leiter instead of Tauchgruppenführer and Führer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 22:21:57 +00:00
msgstr "Tauchgruppenleiter"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:672
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Dives"
msgstr "Tauchgänge"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:1507
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Download From Dive Computer"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Von Tauchcomputer laden"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:915
msgid "Download From Dive Computer..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Von Tauchcomputer laden..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: statistics.c:160
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
msgid "Duration"
msgstr "Dauer"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:862
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Duration (min)"
msgstr "Dauer (min)"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:257
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:659
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit Trip Info"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Reisen-Informationen bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2031
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit Trip Summary"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Reisen-Übersicht bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2007
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit dive"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Tauchgang bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2006
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit dives"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Tauchgänge bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:502
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit multiple dives"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Mehrere Tauchgänge bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:482
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Edit trip summary"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Reisen-Übersicht bearbeiten"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:773
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Enable / Disable Events"
msgstr "Ereignisse Ein-/Ausblenden"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:973 equipment.c:1497
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "End"
msgstr "Ende"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1129 info.c:535
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Equipment"
msgstr "Ausrüstung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:238
msgid "Error parsing the datetime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Analysieren des Datums"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:257
msgid "Error parsing the divetime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Analysieren der Dauer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:284
msgid "Error parsing the gas mix"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Analysieren der Gas Informationen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:277
msgid "Error parsing the gas mix count"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Analysieren der Gas Informationen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:267
msgid "Error parsing the maxdepth"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Analysieren der maximalen Tiefe"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:292
msgid "Error parsing the samples"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Auswerten der Samples"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:367
msgid "Error registering the cancellation handler."
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler bei der Registrierung der Abbruchbehandlung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:229
msgid "Error registering the data"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Registrieren der Daten"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:362
msgid "Error registering the event handler."
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Registrieren der Ereignisbehandlung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:337
#, c-format
msgid "Event: systime=%<PRId64>, devtime=%u\n"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Ereignis: systime=%<PRId64>, devtime=%u\n"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:323
msgid "Event: waiting for user action"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Ereignis: warte auf Benutzer Aktion"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2116
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Expand all"
msgstr "Alle ausfalten"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:603
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Fahrenheit"
msgstr "Fahrenheit"
#: gtk-gui.c:140
#, c-format
msgid "Failed to open %i files."
msgstr "Fehler beim Öffnen von %i Dateien"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: parse-xml.c:1498
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "Failed to parse '%s'"
msgstr "Fehler beim Analysieren von '%s'"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: parse-xml.c:1493
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "Failed to parse '%s'.\n"
msgstr "Fehler beim Analysieren von '%s'.\n"
#: file.c:266
#, c-format
msgid "Failed to read '%s'"
msgstr "Fehler beim Lesen von '%s'"
#: file.c:262
#, c-format
msgid "Failed to read '%s'.\n"
msgstr "Fehler beim Lesen von '%s'.\n"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:46
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Feb"
msgstr "Feb"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:588
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Feet"
msgstr "Fuß"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:903
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "File"
msgstr "Datei"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:906
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Filter"
msgstr "Filter"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Fri"
msgstr "Fr"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:739
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Gas Used"
msgstr "Gasverbrauch"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:983
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Gasmix"
msgstr "Gasmischung"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:907
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Help"
msgstr "Hilfe"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:914
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
msgid "Import XML File(s)..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "XML Datei(en) einlesen..."
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:925
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Info"
msgstr "Informatinen"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#. ++GETTEXT: these are three letter months - we allow up to six code bytes
#: main.c:46
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Jan"
msgstr "Jan"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:47
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Jul"
msgstr "Jul"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:46
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Jun"
msgstr "Jun"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:857
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Linus Torvalds, Dirk Hohndel, and others, 2011, 2012"
msgstr "Linus Torvalds, Dirk Hohndel und andere, 2011, 2012"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:923
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "List"
msgstr "Liste"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:597
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Liter"
msgstr "Liter"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: divelist.c:1273 info.c:487 info.c:509 info.c:936 print.c:156
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Location"
msgstr "Ort"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:904
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Log"
msgstr "Log"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:167
msgctxt "Duration"
msgid "Longest"
msgstr "Max."
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:683
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Longest Dive"
msgstr "Längster Tauchgang"
#: uemis.c:170
msgid "Low Battery Alert"
msgstr "Alarm: Batterie schwach"
#: uemis.c:168
msgid "Low Battery Warning"
msgstr "Warnung: Batterie schwach"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:46
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Mar"
msgstr "Mär"
#: uemis.c:164
msgid "Marker"
msgstr "Markierung"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:155
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Master"
Small adjustments to the German translation Consistently use "Ø" for average. Use Tauchgruppenleiter and Leiter instead of Tauchgruppenführer and Führer. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 22:21:57 +00:00
msgstr "Leiter"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:158
msgid "Max Deco Time Warning"
msgstr "Warnung: Maximale Deco Zeit"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:690 statistics.c:728
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Max Depth"
msgstr "Max. Tiefe"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:698
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Max SAC"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Max. AMV"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:673
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Max Temp"
msgstr "Max. Temp."
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:95
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid ""
"Max depth: %.*f %s\n"
"Duration: %d min\n"
"%s"
msgstr ""
"Max. Tiefe: %.*f %s\n"
"Dauer: %d min\n"
"%s"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1495
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "MaxPress"
msgstr "Max.Druck"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:170
msgctxt "Depth"
msgid "Maximum"
msgstr "Max."
#: statistics.c:173
msgctxt "SAC"
msgid "Maximum"
msgstr "Max."
#: statistics.c:176
msgctxt "Temp"
msgid "Maximum"
msgstr "Max."
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:46
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "May"
msgstr "Mai"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2039
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Merge trip with trip above"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Reise mit der darüber verbinden"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2049
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Merge trip with trip below"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Reise mit der darunter verbinden"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:587
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Meter"
msgstr "Meter"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:691
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Min Depth"
msgstr "Min. Tiefe"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:699
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Min SAC"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Min. AMV"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:674
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Min Temp"
msgstr "Min. Temp."
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:169
msgctxt "Depth"
msgid "Minimum"
msgstr "Min."
#: statistics.c:172
msgctxt "SAC"
msgid "Minimum"
msgstr "Min."
#: statistics.c:175
msgctxt "Temp"
msgid "Minimum"
msgstr "Min."
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:658
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Misc. Options"
msgstr "Verschiedene Optionen"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Mon"
msgstr "Mo"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:853
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Multi-platform divelog software in C"
msgstr "Multi-Platform Tauchprogram in C"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:908
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
msgid "New"
Update German translations for newly added menu strings Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:15:08 +00:00
msgstr "Neu"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:813
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "New starting number"
msgstr "Neue erste Nummer"
#: uemis.c:166
msgid "No Tank Data"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Keine Flaschen Informationen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:492 info.c:527 info.c:950
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Notes"
msgstr "Notizen"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:47
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Nov"
msgstr "Nov"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:82
msgid "OLF"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "OLF"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:1272 gtk-gui.c:637 statistics.c:737
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "OTU"
msgstr "OTU"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:47
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Oct"
msgstr "Okt"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:425
msgid "Odd pthread error return"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Unbekannter pthread Fehlercode"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:315
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Open File"
msgstr "Datei öffnen"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:909
msgid "Open..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Öffnen..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:82
msgid "PO2"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "PO2"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:144
msgid "PO2 Ascend Alarm"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Alarm: Aufstieg / PO2"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:142
msgid "PO2 Ascend Warning"
msgstr "Warnung: Aufstieg / PO2"
#: uemis.c:139
msgid "PO2 Green Warning"
msgstr "Warnung: PO2 Grün"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:593
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "PSI"
msgstr "psi"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:572
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Preferences"
msgstr "Einstellungen"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:917
msgid "Preferences..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Einstellungen..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:962 equipment.c:968
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Pressure"
msgstr "Druck"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:591
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Pressure:"
msgstr "Druck:"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:486
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Pretty print"
msgstr "Schön drucken"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:507
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Print only selected dives"
msgstr "Nur ausgewählte Tauchgänge drucken"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:502
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Print selection"
msgstr "Auswahl drucken"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:480
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Print type"
msgstr "Art des Ausdrucks"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:913
msgid "Print..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Drucken..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:924
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Profile"
msgstr "Profil"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:921
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
msgid "Quit"
Update German translations for newly added menu strings Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:15:08 +00:00
msgstr "Beenden"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:152
msgid "RGT Alert"
msgstr "Alarm: verbleibende Gas-Zeit"
#: uemis.c:150
msgid "RGT Warning"
msgstr "Warnung: verbleibende Gas-Zeit"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:520 info.c:947
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Rating"
msgstr "Bewertung"
#: uemis-downloader.c:267
#, c-format
msgid "Reading dive %s"
msgstr "Lese Tauchgang %s"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2054
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Remove Trip"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Reise entfernen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2110
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Remove dive from trip"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Tauchgang aus Reise entfernen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:2108
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Remove selected dives from trip"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
msgstr "Ausgewählte Tauchgänge aus Reise entfernen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:804
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Renumber"
msgstr "Neu nummerieren"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:918
msgid "Renumber..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Neu nummerieren..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1484
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Retry"
msgstr "Wiederholen"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:1271 gtk-gui.c:632 statistics.c:160 statistics.c:736
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "SAC"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "AMV"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: file.c:75
msgid "SDE file"
msgstr "SDE Datei"
#: uemis.c:132
msgid "Safety Stop Violation"
msgstr "Verletzung des Sicherheitsstops"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Sat"
msgstr "Sa"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:911
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
msgid "Save As..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Speichern unter..."
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: gtk-gui.c:228
msgid "Save Changes?"
msgstr "Änderungen speichern?"
#: gtk-gui.c:165
msgid "Save File As"
msgstr "Datei speichern unter"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:910
msgid "Save..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Speichern..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:764
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "SelectEvents"
msgstr "Ereignisse auswählen"
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#: gtk-gui.c:920
msgid "SelectEvents..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 08:20:00 +00:00
msgstr "Ereignisse auswählen..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:47
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Sep"
msgstr "Sep"
#: uemis-downloader.c:30
msgid ""
"Short write to req.txt file\n"
"Is the Uemis Zurich plugged in correctly?"
msgstr ""
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
"Unvollständiger Schreibvorgang der req.txt Datei\n"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
"Ist der Uemis Zurich korrekt verbunden?"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:166
msgctxt "Duration"
msgid "Shortest"
msgstr "Min."
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:684
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Shortest Dive"
msgstr "Kürzester Tauchgang"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:611
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Show Columns"
msgstr "Spalten anzeigen"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:959 equipment.c:1494
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Size"
msgstr "Größe"
#: uemis.c:134
msgid "Speed Alarm"
msgstr "Alarm: Geschwindigkeit"
#: uemis.c:137
msgid "Speed Warning"
msgstr "Warnung: Geschwindigkeit"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:970 equipment.c:1496
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Start"
msgstr "Start"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:664
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Statistics"
msgstr "Statistiken"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:1137
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Stats"
msgstr "Statistiken"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: divelist.c:1268 gtk-gui.c:647 info.c:521 info.c:948
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Suit"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Anzug"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#. ++GETTEXT: these are three letter days - we allow up to six code bytes
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Sun"
msgstr "So"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:722
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Surf Intv"
Improve German translations The changes were mostly suggested by Lutz, but since he didn't send a patch, I manually applied them. Suggested-by: Lutz Vieweg <lvml@5t9.de> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 00:02:58 +00:00
msgstr "Oberflächenpause"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: print.c:490
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Table print"
msgstr "Tabellenausdruck"
#: uemis.c:154
msgid "Tank Change Suggested"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Flaschenwechsel Vorschlag"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#: uemis.c:148
msgid "Tank Pressure Info"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Info: Flaschendruck"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:617
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Temp"
msgstr "Temperatur"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:160
msgid "Temperature"
msgstr "Temperatur"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:601
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Temperature:"
msgstr "Temperatur:"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:926
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Three"
msgstr "Drei"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Thu"
msgstr "Do"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: info.c:822 print.c:155
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Time"
msgstr "Zeit"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:932
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Toggle Zoom"
msgstr "Zoom ein-/ausschalten"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#: statistics.c:164
msgctxt "Duration"
msgid "Total"
msgstr "Gesamt"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:681
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Total Time"
msgstr "Gesamtzeit"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#. ++GETTEXT 60 char buffer weekday, monthname, day of month, year, nr dives
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:376
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#, c-format
msgid "Trip %1$s, %2$s %3$d, %4$d (%5$d dive)"
msgid_plural "Trip %1$s, %2$s %3$d, %4$d (%5$d dives)"
msgstr[0] "Reise ab %1$s, %3$d. %2$s %4$d (%5$d Tauchgang)"
msgstr[1] "Reise ab %1$s, %3$d. %2$s %4$d (%5$d Tauchgänge)"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Tue"
msgstr "Di"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1493 equipment.c:1521
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Type"
msgstr "Typ"
#: uemis-downloader.c:28
msgid ""
"Uemis Zurich: File System is almost full\n"
"Disconnect/reconnect the dive computer\n"
"and try again"
msgstr ""
"Uemis Zurich: Dateisystem beinahe voll\n"
"Bitte den Tauchcomputer ausstecken und wieder einstecken\n"
"und erneut versuchen"
#: uemis-downloader.c:29
msgid ""
"Uemis Zurich: File System is full\n"
"Disconnect/reconnect the dive computer\n"
"and try again"
msgstr ""
"Uemis Zurich: Dateisystem voll\n"
"Bitte den Tauchcomputer ausstecken und wieder einstecken\n"
"und erneut versuchen"
#: uemis-downloader.c:559
msgid "Uemis init failed"
msgstr "Uemis Initialisierung fehlgeschlagen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:388
msgid "Unable to create libdivecomputer context"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Erzeugen des libdivecomputer Contexts"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:223
#, c-format
msgid "Unable to create parser for %s %s"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Nicht in der Lage, einen Parser für %s %s zu erstellen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:390
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
#, c-format
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
msgid "Unable to open %s %s (%s)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Fehler beim Öffnen von %s %s (%s)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:579
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Units"
msgstr "Einheiten"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:905
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "View"
msgstr "Ansicht"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:596
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Volume:"
msgstr "Volumen:"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:730
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Water Temp"
msgstr "Wassertemperatur"
Make translations of menu entries explicit It appears that at least for Norwegian the translations of the stock menu entries was missing. This patch adds those as explicit strings and merges those new strings into the .po files. The translations need to be updated in separate commits. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 14:08:45 +00:00
#: main.c:37
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Wed"
msgstr "Mi"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1020 equipment.c:1620 gtk-gui.c:642
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Weight"
msgstr "Gewicht"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1125
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Weight System"
msgstr "Gewicht"
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:606
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Weight:"
msgstr "Gewicht:"
#: gtk-gui.c:153
msgid "XML file"
msgstr "XML Datei"
#: statistics.c:160
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
msgid "Year"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Jahr"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:919 statistics.c:368
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "Yearly Statistics"
msgstr "Jährliche Statistiken"
#: gtk-gui.c:238
msgid ""
"You have unsaved changes\n"
"Would you like to save those before closing the datafile?"
msgstr ""
"Nicht alle Änderungen wurden gespeichert.\n"
Slovak translation Also fixed two typos in the German translations. Signed-Off-By: Jozef Ivanecký (dodo.sk@gmail.com) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-12 13:06:35 +00:00
"Sollen Änderungen vor dem Schließen der Datei gespeichert werden?"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: gtk-gui.c:241 gtk-gui.c:244
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid ""
"You have unsaved changes to file: %s \n"
"Would you like to save those before closing the datafile?"
msgstr ""
"Nicht alle Änderungen in der Dati %s wurden gespeichert.\n"
Slovak translation Also fixed two typos in the German translations. Signed-Off-By: Jozef Ivanecký (dodo.sk@gmail.com) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-12 13:06:35 +00:00
"Sollen Änderungen vor dem Schließen der Datei gespeichert werden?"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: divelist.c:639
msgid "air"
Update German and Finnish translations Translate air in the German locales and remove a fuzzy comment next to a correct translation in the Finnish one Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:44:12 +00:00
msgstr "Luft"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:82
msgid "airtime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "verbleibende Atemzeit"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:832
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "ankle"
msgstr "Fuß"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:78
msgid "ascent"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Aufstieg"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:833
Changed the term used for one of the default weight systems Originally I used the colloquial term "bar" for the weight bar that you can attach to a backplate (usually when diving twins in a tec environment). This of course causes an odditity for translations as this word "bar" is a homonym for the weight system and the pressure unit - which throws off translations. Instead of switching to a context-based translation I instead went with a better term: "backplate weight". This of course now needs to be translated, so I updated the .po files (and added German translations for the two flavors of German). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:45:16 +00:00
msgid "backplate weight"
msgstr "Rückenplatten-Gewicht"
#: dive.c:45
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "bar"
msgstr "bar"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:831
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "belt"
msgstr "Gürtel"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:79
msgid "bookmark"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Markierung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:78
msgid "ceiling"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Minimaltiefe"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:81
msgid "ceiling (safety stop)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Minimaltiefe (Sicherheitsstopp)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:834
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "clip-on"
msgstr "clip-on"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: dive.c:88
msgid "cuft"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "cu.ft."
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:78
msgid "deco"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Deko"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:81
msgid "deepstop"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "tiefer Stopp"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:81
msgid "divetime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Dauer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: dive.c:113 divelist.c:1264 info.c:867
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "ft"
msgstr "ft"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:80
msgid "gaschange"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Flaschenwechsel"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:82
msgid "heading"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Richtung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:830
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "integrated"
msgstr "integriert"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:101
msgid "invalid event number"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "ungültige Ereignisnummer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: dive.c:136 equipment.c:1045 gtk-gui.c:607
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "kg"
msgstr "kg"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: dive.c:83
msgid "l"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "l"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: dive.c:132 divelist.c:1267 equipment.c:1047 gtk-gui.c:608
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "lbs"
msgstr "US Pfund"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: dive.c:108 info.c:867
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
msgid "m"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "m"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:82
msgid "maxdepth"
msgstr "Max. Tiefe"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: divelist.c:1265
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "min"
msgstr "min"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:331
#, c-format
msgid "model=%u (0x%08x), firmware=%u (0x%08x), serial=%u (0x%08x)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "model=%u (0x%08x), firmware=%u (0x%08x), serial=%u (0x%08x)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Handle dates and a "calculated plural" in translations This looks like a massive commit mainly because of the line number changes in the .po files. That sadly hides what really happened here: - the places where we manually build dates have now been localized - the one place where we did the English "calculated plural" has been modified so that it now can be correctly translated (in English this just adds an 's' to the noun if the number is != 1 - in other languages this tends to be much more complicated) I then updated the two German translations to take advantage of the new constructs. And while I was at it, I changed the translation Trip->Gruppe to Trip->Reise as that seemed much more appropriate. I also fixed another error in the German translation where I translated "dive time" as "Startzeit" - but in the context it was "Dauer". Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-17 08:21:03 +00:00
#: statistics.c:501
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#, c-format
msgid "more than %d days"
msgstr "mehr als %d Tage"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:78
msgid "none"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "keine"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: dive.c:41
msgid "pascal"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "Pa"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
#: dive.c:49
msgid "psi"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 02:34:28 +00:00
msgstr "psi"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 16:32:09 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:78
msgid "rbt"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "rbt"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:82
msgid "rgbm"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "rgbm"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:79
msgid "safety stop"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Sicherheitsstopp"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:80
msgid "safety stop (mandatory)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Sicherheitsstopp (verpflichtend)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:80
msgid "safety stop (voluntary)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Sicherheitsstopp (freiwillig)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:79
msgid "surface"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Oberfläche"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:83
msgid "tissue level warning"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Warnung auf Gewebe-Ebene"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
#: gtk-gui.c:858
msgid "translator-credits"
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:46:15 +00:00
msgstr "Dirk Hohndel"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 05:41:41 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:79
msgid "transmitter"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Sender"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1386 equipment.c:1406
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "unkn"
msgstr "unbk"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:81 statistics.c:541
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "unknown"
msgstr "unbekannt"
#: equipment.c:544
msgid "unspecified"
msgstr "nicht angegeben"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:79
msgid "violation"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Verletzung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 15:42:18 +00:00
#: equipment.c:1522
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
msgid "weight"
msgstr "Gewicht"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
#: libdivecomputer.c:78
msgid "workload"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:42:20 +00:00
msgstr "Arbeit"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 21:22:29 +00:00
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 07:50:45 +00:00
#~ msgid "About"
#~ msgstr "Info"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-15 03:43:32 +00:00
#~ msgctxt "Depth"
#~ msgid ""
#~ "Depth\n"
#~ "Average"
#~ msgstr ""
#~ "Tiefe\n"
#~ "Ø"
#~ msgctxt "Duration"
#~ msgid ""
#~ "Duration\n"
#~ "Total"
#~ msgstr ""
#~ "Dauer\n"
#~ "Gesamt"
#~ msgctxt "SAC"
#~ msgid ""
#~ "SAC\n"
#~ "Average"
#~ msgstr ""
#~ "AMV\n"
#~ "Ø"
#, fuzzy
#~ msgid ""
#~ "SAC|\n"
#~ "Minimum"
#~ msgstr ""
#~ "\n"
#~ "Min."
#~ msgctxt "Temp"
#~ msgid ""
#~ "Temperature\n"
#~ "Average"
#~ msgstr ""
#~ "Temperatur\n"
#~ "Ø"
Reference in a new issue Copy permalink