mifr/subsurface
1
0
Fork 0
mirror of https://github.com/subsurface/subsurface.git synced 2024-11-28 13:10:19 +00:00
Code Issues Projects Releases Packages Wiki Activity
subsurface/po/de_DE.po

1101 lines
18 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"
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
"POT-Creation-Date: 2012-10-18 09:28-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
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:1504
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 "#"
msgstr ""
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)"
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:920
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 "About"
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 "Info"
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:914
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: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"
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:929
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 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
#: info.c:514 info.c:941 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
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:1398
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"
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:910
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"
msgstr "Tank"
#: equipment.c:926 equipment.c:1062
msgid "Cylinder"
msgstr "Tank"
#: equipment.c:1572
msgid "Cylinders"
msgstr "Tanks"
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 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
#: info.c:806
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 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
#: info.c:816
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 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
#: info.c:255
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 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
#: info.c:206
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 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
#: info.c:866
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:"
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:1366
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 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
#: info.c:158 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 - "
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
#: gtk-gui.c:1122 info.c:699 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"
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:1114
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
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:1335
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"
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 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
#: info.c:513
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 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
#: info.c:940
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"
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:913 gtk-gui.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 "Download From Dive Computer"
msgstr "Vom Tauchcomputer runterladen"
#: 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 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
#: info.c:861
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 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
#: 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 "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 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
#: info.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 "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 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
#: info.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
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 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
#: info.c:481
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"
#: equipment.c:965 equipment.c:1489
msgid "End"
msgstr "Ende"
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
#: gtk-gui.c:1118 info.c:534
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"
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ß"
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:901
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"
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: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 "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"
#: equipment.c:975
msgid "Gasmix"
msgstr "Gasmischung"
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: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 "Help"
msgstr "Hilfe"
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:912
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 "Import XML File(s)"
msgstr "XML Datei(en) einlesen"
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: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 "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"
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:856
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"
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:921
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 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:1273 info.c:486 info.c:508 info.c:935 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"
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:902
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"
#: equipment.c:1487
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"
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:906
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"
msgstr "Keine Tank Informationen"
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
#: info.c:491 info.c:526 info.c:949
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"
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"
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:907
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 "Open"
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 "Öffnen"
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: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"
#: 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"
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:572 gtk-gui.c:915
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"
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
#: equipment.c:954 equipment.c:960
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
#: gtk-gui.c:911
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 "Print"
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 "Drucken"
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
#: 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"
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:922
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"
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:919
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 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
#: info.c:519 info.c:946
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
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:804 gtk-gui.c:916
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"
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:1473
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"
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: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 "Save"
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 "Speichern"
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:909
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 "Save As"
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 "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"
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:764 gtk-gui.c:918
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"
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"
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
#: equipment.c:951 equipment.c:1486
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"
#: equipment.c:962 equipment.c:1488
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"
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:1126
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 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:1268 gtk-gui.c:647 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 "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"
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 "Tankwechsel 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"
msgstr "Info: Tankdruck"
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:"
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: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 "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 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
#: info.c:821 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"
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:930
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"
#: equipment.c:1485 equipment.c:1513
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"
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"
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: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 "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"
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
#: equipment.c:1012 equipment.c:1609 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"
#: equipment.c:1117
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"
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
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
#: gtk-gui.c:917 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
#: equipment.c:824
msgid "ankle"
msgstr "Fuß"
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:45 equipment.c:825
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"
#: equipment.c:823
msgid "belt"
msgstr "Gürtel"
#: equipment.c:826
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"
msgstr ""
#: dive.c:113 divelist.c:1264 info.c:866
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"
#: equipment.c:822
msgid "integrated"
msgstr "integriert"
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:136 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"
msgstr ""
#: dive.c:132 divelist.c:1267 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 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:108 info.c:866
msgid "m"
msgstr ""
#: 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"
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"
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"
msgstr ""
#: dive.c:49
msgid "psi"
msgstr ""
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
#: equipment.c:1378 equipment.c:1398
msgid "unkn"
msgstr "unbk"
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: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"
#: equipment.c:1514
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
#~ msgctxt "Depth"
#~ msgid ""
#~ "Depth\n"
#~ "Average"
#~ msgstr ""
#~ "Tiefe\n"
#~ "Ø"
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 "Dive #%d - %s"
#~ msgstr "Tauchgang #%d - %s"
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 "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