mifr/subsurface
1
0
Fork 0
mirror of https://github.com/subsurface/subsurface.git synced 2025-02-19 22:16:15 +00:00
Code Issues Projects Releases Packages Wiki Activity
subsurface/po/de_DE.po

2009 lines
34 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-14 20:43:32 -07: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 09:42:59 +09:00
# Dirk Hohndel <dirk@hohndel.org>, 2012.
#
msgid ""
msgstr ""
"Project-Id-Version: 2.0.1\n"
"Report-Msgid-Bugs-To: \n"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
"POT-Creation-Date: 2013-02-01 18:08+1100\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 09:42:59 +09: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"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:184
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-14 20:43:32 -07:00
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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:234
msgid " Download"
msgstr ""
#: download-dialog.c:375
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid " Please select dive computer and device. "
msgstr " Bitte Tauchcomputer und Gerät auswählen. "
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:182
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-14 20:43:32 -07:00
msgid "#"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Nr."
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 20:43:32 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:322
#, fuzzy, c-format
msgid "%.*f %s"
msgstr "%.*f %s/min"
#: print.c:267 print.c:340
#, fuzzy, c-format
msgid "%.*f %s\n"
msgstr "%.*f %s/min"
#: statistics.c:588 statistics.c:735 statistics.c:737 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 09:42:59 +09:00
#, c-format
msgid "%.*f %s/min"
msgstr "%.*f %s/min"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:540
#, c-format
msgid "%.0f%s of %s\n"
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 01:21:03 -07:00
#. ++GETTEXT 80 chars: lead text ("" or localized "Dive #%d - ") weekday, monthname, day, year, hour, min
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:76
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 01:21:03 -07:00
#, 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
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:584
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 01:21:03 -07:00
#, 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
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:277
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 01:21:03 -07: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
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:551
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 01:21:03 -07:00
#, 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"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:609 statistics.c:558
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "%d min"
msgstr "%d min"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:528
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "%dd %dh %dmin"
msgstr "%dt %dst %dmin"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:530
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "%dh %dmin"
msgstr "%dst %dmin"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:318
#, c-format
msgid "%s"
msgstr ""
#: profile.c:2144
#, c-format
msgid ""
"%s\n"
"CNS:%u%%"
msgstr ""
#: profile.c:2112
#, c-format
msgid ""
"%s\n"
"Calculated ceiling %.0f %s"
msgstr ""
#: profile.c:2128
#, c-format
msgid ""
"%s\n"
"Deco:%umin @ %.0f %s"
msgstr ""
#: profile.c:2131
#, c-format
msgid ""
"%s\n"
"Deco:unkn time @ %.0f %s"
msgstr ""
#: profile.c:2168
#, c-format
msgid ""
"%s\n"
"EAD:%d%s\n"
"END:%d%s\n"
"EADD:%d%s"
msgstr ""
#: profile.c:2137
#, c-format
msgid ""
"%s\n"
"In deco"
msgstr ""
#: profile.c:2161
#, c-format
msgid ""
"%s\n"
"MOD:%d%s"
msgstr ""
#: profile.c:2140
#, c-format
msgid ""
"%s\n"
"NDL:%umin"
msgstr ""
#: profile.c:2102
#, c-format
msgid ""
"%s\n"
"P:%d %s"
msgstr ""
#: profile.c:2120
#, c-format
msgid ""
"%s\n"
"Safetystop:%umin @ %.0f %s"
msgstr ""
#: profile.c:2123
#, c-format
msgid ""
"%s\n"
"Safetystop:unkn time @ %.0f %s"
msgstr ""
#: profile.c:2107
#, c-format
msgid ""
"%s\n"
"T:%.1f %s"
msgstr ""
#: profile.c:2156
#, c-format
msgid ""
"%s\n"
"pHe:%.2fbar"
msgstr ""
#: profile.c:2152
#, c-format
msgid ""
"%s\n"
"pN%s:%.2fbar"
msgstr ""
#: profile.c:2148
#, c-format
msgid ""
"%s\n"
"pO%s:%.2fbar"
msgstr ""
#: dive.c:762
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "(%s) or (%s)"
msgstr "(%s) oder (%s)"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:680
#, fuzzy, c-format
msgid "(no dives)"
msgstr "Tauchgänge bearbeiten"
#: gtk-gui.c:1995
msgid "(nothing)"
msgstr ""
#: planner.c:1226
msgid "0.6 cuft/min"
msgstr ""
#: planner.c:1225
msgid "0.7 cuft/min"
msgstr ""
#: print.c:907
msgid "1 dive per page"
msgstr ""
#: planner.c:1231
msgid "17 l/min"
msgstr ""
#: uemis-downloader.c:590
msgid "2 pcs full suit"
msgstr ""
#: planner.c:1230
msgid "20 l/min"
msgstr ""
#: gtk-gui.c:833
msgid "3m increments for calculated ceiling"
msgstr ""
#: print.c:903
msgid "6 dives per page"
msgstr ""
#: planner.c:1203
msgid ""
"<small>Add segments below.\n"
"Each line describes part of the planned dive.\n"
"An entry with depth, time and gas describes a segment that ends at the given "
"depth, takes the given time (if relative, e.g. '+3:30') or ends at the given "
"time (if absolute), and uses the given gas.\n"
"An empty gas means 'use previous gas' (or AIR if no gas was specified).\n"
"An entry that has a depth and a gas given but no time is special; it informs "
"the planner that the gas specified is available for the ascent once the "
"depth given has been reached.\n"
"CC SetPoint specifies CC (rebreather) dives, leave empty for OC.</small>"
msgstr ""
#: planner.c:1113
msgid "AIR"
msgstr ""
#: gtk-gui.c:1054 gtk-gui.c:1377
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:41:41 -07:00
msgid "About Subsurface"
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:46:15 -07:00
msgstr "Info zu Subsurface"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:41:41 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1368
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Add Dive..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Tauchgang hinzufügen..."
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2364
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Add dive"
msgstr "Tauchgang hinzufügen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2462
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1250
msgid "Add waypoint"
msgstr ""
#: statistics.c:845
msgid "Air Press"
msgstr ""
#: statistics.c:844
#, fuzzy
msgid "Air Temp"
msgstr "Ø Temp"
#: info.c:714
#, c-format
msgid "Air Temp in %s"
msgstr ""
#: download-dialog.c:391
msgid "Always prefer downloaded dive"
msgstr ""
#: main.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Apr"
msgstr "Apr"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:72
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Aug"
msgstr "Aug"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1390
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Autogroup"
msgstr "Automatisch gruppieren"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:190
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-14 20:43:32 -07:00
msgctxt "Depth"
msgid "Average"
msgstr "Ø"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:187
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-14 20:43:32 -07:00
msgctxt "Duration"
msgid "Average"
msgstr "Ø"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:193
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-14 20:43:32 -07:00
msgctxt "SAC"
msgid "Average"
msgstr "Ø"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:196
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-14 20:43:32 -07:00
msgctxt "Temp"
msgid "Average"
msgstr "Ø"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:799 statistics.c:836
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 15:21:57 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:807
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:782
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 15:21:57 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:789
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 15:21:57 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:634
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Bar"
msgstr "bar"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:700 info.c:1153 print.c:511
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Buddy"
msgstr "Partner"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1142
msgid "CC SetPoint"
msgstr ""
#: uemis-downloader.c:908
msgid "Cancelled, exiting cleanly..."
msgstr ""
#: libdivecomputer.c:756
msgid "Cancelled..."
msgstr ""
#: webservice.c:27
msgid "Cannot parse response!"
msgstr ""
#: gtk-gui.c:644
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Celsius"
msgstr "Celsius"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:556
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1896
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1363
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 23:08:45 +09:00
msgid "Close"
Update German translations for newly added menu strings Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 23:15:08 +09: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 23:08:45 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2480
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Collapse all"
msgstr "Alle einfalten"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:119
msgid "Connecting..."
msgstr ""
#: webservice.c:23
msgid "Connection Error: "
msgstr ""
#: divelist.c:2452
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:640
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "CuFt"
msgstr "cuft"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:1423 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 09:42:59 +09:00
msgid "Cyl"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Flasche"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:918 equipment.c:1029 print.c:205
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Cylinder"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Flasche"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:1539
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Cylinders"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Flaschen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: profile.c:2098
#, fuzzy, c-format
msgid "D:%.1f %s"
msgstr "%.*f %s/min"
#: divelist.c:1416 print.c:510 statistics.c:827
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Date"
msgstr "Datum"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:1001
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Date and Time"
msgstr "Datum und Zeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:1011
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Date:"
msgstr "Datum:"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:72
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Dec"
msgstr "Dez"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:701
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1310
msgid "Delete a dive computer information entry"
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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2206 divelist.c:2259 divelist.c:2351
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Delete dive"
msgstr "Tauchgang löschen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2208 divelist.c:2350
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Delete dives"
msgstr "Tauchgänge löschen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:510 statistics.c:182
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Depth"
msgstr "Tiefe"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:1078
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Depth (%s):"
msgstr "Tiefe (%s):"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:222
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:628
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Depth:"
msgstr "Tiefe:"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1269
#, fuzzy
msgid "Device Id"
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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: download-dialog.c:330
msgid "Device or mount point"
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 01:21:03 -07:00
#. ++GETTEXT 80 char buffer: dive nr, weekday, month, day, year, hour, min
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:105
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 01:21:03 -07:00
#, 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"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:157 print.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Dive #%d - "
msgstr "Tauchgang #%d - "
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:435
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:46:15 -07:00
#, c-format
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Dive %d: %s %d %04d"
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:46:15 -07:00
msgstr "Tauchgang Nr. %d: %s %d %04d"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1977
#, fuzzy
msgid "Dive Computer Nickname"
msgstr "Tauchcomputer"
#: gtk-gui.c:1607 info.c:898 statistics.c:818
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Dive Info"
msgstr "Informationen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1599
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Dive Notes"
msgstr "Notizen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1194
msgid "Dive Plan - THIS IS JUST A SIMULATION; DO NOT USE FOR DIVING"
msgstr ""
#: statistics.c:828
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:228
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:226
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: download-dialog.c:288
msgid "Dive computer vendor and product"
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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:680
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Dive data import error"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Importieren der Daten des Tauchgangs"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:893
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Dive details"
msgstr "Notizen zum Tauchgang"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gps.c:193
#, fuzzy
msgid "Dive locations"
msgstr "Notizen"
#: info.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 09:42:59 +09: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 15:21:57 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1219
msgid "Dive starts when?"
msgstr ""
#: print.c:510
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Dive#"
msgstr "Tauchgang Nr."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:689
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Divelist Font"
msgstr "Schriftart für Tauchliste"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:1152
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 15:21:57 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:779
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Dives"
msgstr "Tauchgänge"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1373
#, fuzzy
msgid "Dives Locations"
msgstr "Ort"
#: download-dialog.c:366
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Download From Dive Computer"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Von Tauchcomputer laden"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1366
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Download From Dive Computer..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Von Tauchcomputer laden..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:207
#, fuzzy
msgid "Download From Web Service"
msgstr "Von Tauchcomputer laden"
#: gtk-gui.c:1367
#, fuzzy
msgid "Download From Web Service..."
msgstr "Von Tauchcomputer laden..."
#: webservice.c:29
msgid "Download Success!"
msgstr ""
#: statistics.c:182
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-14 20:43:32 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:1073
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Duration (min)"
msgstr "Dauer (min)"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:629
msgid "E"
msgstr ""
#: planner.c:76
#, c-format
msgid "EAN%d"
msgstr ""
#: planner.c:1114
msgid "EAN32"
msgstr ""
#: planner.c:1115
msgid "EAN36"
msgstr ""
#: info.c:222
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1382
#, fuzzy
msgid "Edit Device Names"
msgstr "Gerätename"
#: gtk-gui.c:1242
msgid "Edit Dive Computer Nicknames"
msgstr ""
#: info.c:857
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2372
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1302
msgid ""
"Edit a dive computer nickname by double-clicking the in the relevant "
"nickname field"
msgstr ""
#: divelist.c:2348
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2405 divelist.c:2424
#, fuzzy
msgid "Edit dive date/time"
msgstr "Tauchgang bearbeiten"
#: divelist.c:2347
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.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 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.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 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:953
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Enable / Disable Events"
msgstr "Ereignisse Ein-/Ausblenden"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:949 equipment.c:1456
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "End"
msgstr "Ende"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1139
#, fuzzy
msgid "Ending Depth"
msgstr "Min. Tiefe"
#: webservice.c:220
msgid ""
"Enter a user identifier and press 'Download'. Once the download is complete "
"you can press 'Apply' if you wish to apply the changes."
msgstr ""
#: gtk-gui.c:1603 info.c:733
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Equipment"
msgstr "Ausrüstung"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:470
#, fuzzy
msgid "Error obtaining water salinity"
msgstr "Fehler beim Auswerten der Samples"
#: libdivecomputer.c:418
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error parsing the datetime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Analysieren des Datums"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:440
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error parsing the divetime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Analysieren der Dauer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:479
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error parsing the gas mix"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Analysieren der Gas Informationen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:460
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error parsing the gas mix count"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Analysieren der Gas Informationen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:450
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error parsing the maxdepth"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Analysieren der maximalen Tiefe"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:487
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error parsing the samples"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Auswerten der Samples"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:676
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error registering the cancellation handler."
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler bei der Registrierung der Abbruchbehandlung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:409
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error registering the data"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Registrieren der Daten"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:671
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Error registering the event handler."
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Registrieren der Ereignisbehandlung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:644
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
#, c-format
msgid "Event: systime=%<PRId64>, devtime=%u\n"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Ereignis: systime=%<PRId64>, devtime=%u\n"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:621
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Event: waiting for user action"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Ereignis: warte auf Benutzer Aktion"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2476
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Expand all"
msgstr "Alle ausfalten"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:645
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Fahrenheit"
msgstr "Fahrenheit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:112
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Failed to open %i files."
msgstr "Fehler beim Öffnen von %i Dateien"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: parse-xml.c:1448
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Failed to parse '%s'"
msgstr "Fehler beim Analysieren von '%s'"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: parse-xml.c:1443
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Failed to parse '%s'.\n"
msgstr "Fehler beim Analysieren von '%s'.\n"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: file.c:265
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Failed to read '%s'"
msgstr "Fehler beim Lesen von '%s'"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: file.c:261
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#, c-format
msgid "Failed to read '%s'.\n"
msgstr "Fehler beim Lesen von '%s'.\n"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Feb"
msgstr "Feb"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:630
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Feet"
msgstr "Fuß"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1353
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "File"
msgstr "Datei"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1356
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Filter"
msgstr "Filter"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: download-dialog.c:385
msgid "Force download of all dives"
msgstr ""
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Fri"
msgstr "Fr"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:851
msgid "GFhigh"
msgstr ""
#: planner.c:1242
msgid "GFhigh for plan"
msgstr ""
#: gtk-gui.c:841
msgid "GFlow"
msgstr ""
#: planner.c:1241
msgid "GFlow for plan"
msgstr ""
#: info.c:683
msgid "GPS (WGS84 or GPS format)"
msgstr ""
#: planner.c:1141 print.c:205 statistics.c:854
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Gas Used"
msgstr "Gasverbrauch"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:529
#, c-format
msgid "Gas consumption:\n"
msgstr ""
#: equipment.c:959 print.c:205
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Gasmix"
msgstr "Gasmischung"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:621
msgid "General Settings"
msgstr ""
#: gtk-gui.c:1358
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Help"
msgstr "Hilfe"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:241
msgid "Idle"
msgstr ""
#: gtk-gui.c:1365
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Import XML File(s)..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "XML Datei(en) einlesen..."
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1380
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Info"
msgstr "Informatinen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:761
msgid "Init Communication"
msgstr ""
#: gtk-gui.c:1385
msgid "Input Plan"
msgstr ""
#: webservice.c:25
msgid "Invalid user identifier!"
msgstr ""
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 23:08:45 +09:00
#. ++GETTEXT: these are three letter months - we allow up to six code bytes
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Jan"
msgstr "Jan"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:72
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Jul"
msgstr "Jul"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Jun"
msgstr "Jun"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1060
#, fuzzy
msgid "Linus Torvalds, Dirk Hohndel, and others, 2011, 2012, 2013"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgstr "Linus Torvalds, Dirk Hohndel und andere, 2011, 2012"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1378
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "List"
msgstr "Liste"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:639
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Liter"
msgstr "Liter"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:1428 info.c:606 info.c:676 info.c:1147 print.c:511
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Location"
msgstr "Ort"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1354
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Log"
msgstr "Log"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:189
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-14 20:43:32 -07:00
msgctxt "Duration"
msgid "Longest"
msgstr "Max."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:790
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Longest Dive"
msgstr "Längster Tauchgang"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:236
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Low Battery Alert"
msgstr "Alarm: Batterie schwach"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:234
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Low Battery Warning"
msgstr "Warnung: Batterie schwach"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Mar"
msgstr "Mär"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gps.c:56
msgid "Mark location here"
msgstr ""
#: uemis.c:230
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Marker"
msgstr "Markierung"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:510
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 15:21:57 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:224
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Max Deco Time Warning"
msgstr "Warnung: Maximale Deco Zeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:797 statistics.c:835
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Max Depth"
msgstr "Max. Tiefe"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:805
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:780
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Max Temp"
msgstr "Max. Temp."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:103
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:385
#, c-format
msgid "Max. CNS"
msgstr ""
#: equipment.c:1454
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "MaxPress"
msgstr "Max.Druck"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:192
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-14 20:43:32 -07:00
msgctxt "Depth"
msgid "Maximum"
msgstr "Max."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:195
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-14 20:43:32 -07:00
msgctxt "SAC"
msgid "Maximum"
msgstr "Max."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:198
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-14 20:43:32 -07:00
msgctxt "Temp"
msgid "Maximum"
msgstr "Max."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:71
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "May"
msgstr "Mai"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2339
#, fuzzy
msgid "Merge dives"
msgstr "Tauchgänge löschen"
#: divelist.c:2380
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2390
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.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 09:42:59 +09:00
msgid "Meter"
msgstr "Meter"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:798
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Min Depth"
msgstr "Min. Tiefe"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.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 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:781
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Min Temp"
msgstr "Min. Temp."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:191
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-14 20:43:32 -07:00
msgctxt "Depth"
msgid "Minimum"
msgstr "Min."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:194
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-14 20:43:32 -07:00
msgctxt "SAC"
msgid "Minimum"
msgstr "Min."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:197
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-14 20:43:32 -07:00
msgctxt "Temp"
msgid "Minimum"
msgstr "Min."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:695
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Misc. Options"
msgstr "Verschiedene Optionen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1264
msgid "Model"
msgstr ""
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Mon"
msgstr "Mo"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1056
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Multi-platform divelog software in C"
msgstr "Multi-Platform Tauchprogram in C"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:628
msgid "N"
msgstr ""
#: gtk-gui.c:1359
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 23:08:45 +09:00
msgid "New"
Update German translations for newly added menu strings Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 23:15:08 +09: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 23:08:45 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1004
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "New starting number"
msgstr "Neue erste Nummer"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1384
msgid "Next DC"
msgstr ""
#: gtk-gui.c:1274 gtk-gui.c:1999
#, fuzzy
msgid "Nickname"
msgstr "Gerätename"
#: uemis.c:232
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "No Tank Data"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Keine Flaschen Informationen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:611 info.c:725 info.c:1161
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Notes"
msgstr "Notizen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:72
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Nov"
msgstr "Nov"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:153
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "OLF"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "OLF"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:1426 gtk-gui.c:722 print.c:363 statistics.c:852
#, c-format
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "OTU"
msgstr "OTU"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:72
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Oct"
msgstr "Okt"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:769
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Odd pthread error return"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Unbekannter pthread Fehlercode"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1321
msgid "Ok to delete the selected entry?"
msgstr ""
#: gtk-gui.c:268
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Open File"
msgstr "Datei öffnen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1360
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Open..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Öffnen..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:178
#, c-format
msgid "Oxygen"
msgstr ""
#: libdivecomputer.c:153
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "PO2"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "PO2"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:210
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:208
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "PO2 Ascend Warning"
msgstr "Warnung: Aufstieg / PO2"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:205
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "PO2 Green Warning"
msgstr "Warnung: PO2 Grün"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:635
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "PSI"
msgstr "psi"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:686
msgid "Pick on map"
msgstr ""
#: gtk-gui.c:1357
msgid "Planner"
msgstr ""
#: 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 09:42:59 +09:00
msgid "Preferences"
msgstr "Einstellungen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1369
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Preferences..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Einstellungen..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:938 equipment.c:944
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Pressure"
msgstr "Druck"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:633
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Pressure:"
msgstr "Druck:"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1383
msgid "Prev DC"
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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.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 09:42:59 +09:00
msgid "Print only selected dives"
msgstr "Nur ausgewählte Tauchgänge drucken"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:925
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Print selection"
msgstr "Auswahl drucken"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:897
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Print type"
msgstr "Art des Ausdrucks"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1364
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Print..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Drucken..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1379
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Profile"
msgstr "Profil"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:732
#, fuzzy
msgid "Profile Settings"
msgstr "Profil"
#: gtk-gui.c:1376
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 23:08:45 +09:00
msgid "Quit"
Update German translations for newly added menu strings Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 23:15:08 +09: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 23:08:45 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:218
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "RGT Alert"
msgstr "Alarm: verbleibende Gas-Zeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:216
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "RGT Warning"
msgstr "Warnung: verbleibende Gas-Zeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:705 info.c:1158
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Rating"
msgstr "Bewertung"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:364
#, fuzzy, c-format
msgid "Reading %s %s"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgstr "Lese Tauchgang %s"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2051 divelist.c:2395
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2470
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:2468
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 01:21:03 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:995
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Renumber"
msgstr "Neu nummerieren"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1370
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Renumber..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Neu nummerieren..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: download-dialog.c:141
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Retry"
msgstr "Wiederholen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:628
msgid "S"
msgstr ""
#: divelist.c:1425 gtk-gui.c:674 print.c:410 statistics.c:182 statistics.c:851
#, c-format
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1236
msgid "SAC during decostop"
msgstr ""
#: planner.c:1235
#, fuzzy
msgid "SAC during dive"
msgstr "Tauchgang hinzufügen"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
#: file.c:75
msgid "SDE file"
msgstr "SDE Datei"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:198
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Safety Stop Violation"
msgstr "Verletzung des Sicherheitsstops"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Sat"
msgstr "Sa"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1362
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Save As..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07: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 23:08:45 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:198
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Save Changes?"
msgstr "Änderungen speichern?"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:135
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Save File As"
msgstr "Datei speichern unter"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1361
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
msgid "Save..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Speichern..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1140
#, fuzzy
msgid "Segment Time"
msgstr "Ø Dauer"
#: gtk-gui.c:944
#, fuzzy
msgid "Select Events"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgstr "Ereignisse auswählen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1375
#, fuzzy
msgid "Select Events..."
Feeble attempt to deal with the last translation change In all languages. Including the one I can't even read. It should be trivial, but the translators really should check. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 01:20:00 -07:00
msgstr "Ereignisse auswählen..."
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:72
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
"Ist der Uemis Zurich korrekt verbunden?"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:188
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-14 20:43:32 -07:00
msgctxt "Duration"
msgid "Shortest"
msgstr "Min."
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:791
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Shortest Dive"
msgstr "Kürzester Tauchgang"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:653 gtk-gui.c:716
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Show Columns"
msgstr "Spalten anzeigen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:812
msgid "Show EAD, END, EADD"
msgstr ""
#: gtk-gui.c:795
msgid "Show MOD"
msgstr ""
#: gtk-gui.c:828
msgid "Show calculated ceiling"
msgstr ""
#: gtk-gui.c:820
msgid "Show dc reported ceiling in red"
msgstr ""
#: divelist.c:2441
msgid "Show in map"
msgstr ""
#: gtk-gui.c:778
msgid "Show pHe graph"
msgstr ""
#: gtk-gui.c:759
#, c-format
msgid "Show pN%s graph"
msgstr ""
#: gtk-gui.c:740
#, c-format
msgid "Show pO%s graph"
msgstr ""
#: planner.c:191
#, fuzzy
msgid "Simulated Dive"
msgstr "Tauchgang löschen"
#: equipment.c:935 equipment.c:1453
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Size"
msgstr "Größe"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:200
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Speed Alarm"
msgstr "Alarm: Geschwindigkeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:203
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Speed Warning"
msgstr "Warnung: Geschwindigkeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:946 equipment.c:1455
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Start"
msgstr "Start"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:774
msgid "Start download"
msgstr ""
#: statistics.c:769
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Statistics"
msgstr "Statistiken"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:705
#, fuzzy, c-format
msgid "Statistics %s"
msgstr "Statistiken"
#: gtk-gui.c:1611
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Stats"
msgstr "Statistiken"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:240
#, fuzzy
msgid "Status"
msgstr "Statistiken"
#: planner.c:511
#, c-format
msgid "Stay at %.*f %s for %d:%02d min - runtime %d:%02u on %s\n"
msgstr ""
#: planner.c:461
#, c-format
msgid ""
"Subsurface dive plan\n"
"based on GFlow = %.0f and GFhigh = %.0f\n"
"\n"
msgstr ""
#: divelist.c:1422 gtk-gui.c:684 info.c:706 info.c:1159
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09: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 23:08:45 +09:00
#. ++GETTEXT: these are three letter days - we allow up to six code bytes
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Sun"
msgstr "So"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:829
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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-13 17:02:58 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: planner.c:1220
msgid "Surface Pressure (mbar)"
msgstr ""
#: planner.c:521
#, c-format
msgid "Switch gas to %s\n"
msgstr ""
#: print.c:911
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Table print"
msgstr "Tabellenausdruck"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:220
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Tank Change Suggested"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Flaschenwechsel Vorschlag"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis.c:214
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Tank Pressure Info"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Info: Flaschendruck"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:714
msgid "Tec Settings"
msgstr ""
#: gtk-gui.c:659
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Temp"
msgstr "Temperatur"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:182
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-14 20:43:32 -07:00
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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:643
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Temperature:"
msgstr "Temperatur:"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1381
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Three"
msgstr "Drei"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Thu"
msgstr "Do"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:1016 print.c:510
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Time"
msgstr "Zeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1497
msgid ""
"To edit dive information\n"
"double click on it in the dive list"
msgstr ""
#: gtk-gui.c:1391
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Toggle Zoom"
msgstr "Zoom ein-/ausschalten"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:186
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-14 20:43:32 -07:00
msgctxt "Duration"
msgid "Total"
msgstr "Gesamt"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:788
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Total Time"
msgstr "Gesamtzeit"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: print.c:336
#, fuzzy, c-format
msgid "Total Weight:"
msgstr "Gewicht:"
#: planner.c:502
#, c-format
msgid "Transition to %.*f %s in %d:%02d min - runtime %d:%02u on %s\n"
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 01:21:03 -07:00
#. ++GETTEXT 60 char buffer weekday, monthname, day of month, year, nr dives
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:268
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 01:21:03 -07: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)"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Tue"
msgstr "Di"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:1452 equipment.c:1480
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Type"
msgstr "Typ"
#: uemis-downloader.c:28
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#, fuzzy
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid ""
"Uemis Zurich: File System is almost full\n"
"Disconnect/reconnect the dive computer\n"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
"and click 'Retry'"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
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"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:763
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Uemis init failed"
msgstr "Uemis Initialisierung fehlgeschlagen"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:698
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Unable to create libdivecomputer context"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Erzeugen des libdivecomputer Contexts"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:403
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
#, c-format
msgid "Unable to create parser for %s %s"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Nicht in der Lage, einen Parser für %s %s zu erstellen"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:700
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
#, c-format
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "Unable to open %s %s (%s)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Fehler beim Öffnen von %s %s (%s)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: 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 09:42:59 +09:00
msgid "Units"
msgstr "Einheiten"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:227
msgid "User Identifier"
msgstr ""
#: gtk-gui.c:1355
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "View"
msgstr "Ansicht"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:711 statistics.c:837
msgid "Visibility"
msgstr ""
#: gtk-gui.c:638
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Volume:"
msgstr "Volumen:"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: info.c:629
msgid "W"
msgstr ""
#: statistics.c:843
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Water Temp"
msgstr "Wassertemperatur"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: webservice.c:255
msgid "Webservice"
msgstr ""
#: main.c:62
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Wed"
msgstr "Mi"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:985 equipment.c:1579 gtk-gui.c:679
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Weight"
msgstr "Gewicht"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:1084 print.c:304
#, c-format
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Weight System"
msgstr "Gewicht"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:648
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Weight:"
msgstr "Gewicht:"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:123
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "XML file"
msgstr "XML Datei"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: statistics.c:182
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-14 20:43:32 -07:00
msgid "Year"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Jahr"
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1371 statistics.c:390
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "Yearly Statistics"
msgstr "Jährliche Statistiken"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1985
#, c-format
msgid ""
"You already have a dive computer of this model\n"
"named %s\n"
"Subsurface can maintain a nickname for this device to distinguish it from "
"the existing one. The default is the model and device ID as shown below.\n"
"If you don't want to name this dive computer click 'Cancel' and Subsurface "
"will simply display its model as its name (which may mean that you cannot "
"tell the two dive computers apart in the logs)."
msgstr ""
#: gtk-gui.c:208
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
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 06:06:35 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:211 gtk-gui.c:214
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09: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 06:06:35 -07: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 09:42:59 +09:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: divelist.c:544 planner.c:74 planner.c:725 print.c:183 profile.c:399
#, c-format
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 08:42:18 -07:00
msgid "air"
Update German and Finnish translations Translate air in the German locales and remove a fuzzy comment next to a correct translation in the Finnish one Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 08:44:12 -07:00
msgstr "Luft"
Update po files NO other changes. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-19 08:42:18 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:153
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "airtime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "verbleibende Atemzeit"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:828
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "ankle"
msgstr "Fuß"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:149
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "ascent"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Aufstieg"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:829
Changed the term used for one of the default weight systems Originally I used the colloquial term "bar" for the weight bar that you can attach to a backplate (usually when diving twins in a tec environment). This of course causes an odditity for translations as this word "bar" is a homonym for the weight system and the pressure unit - which throws off translations. Instead of switching to a context-based translation I instead went with a better term: "backplate weight". This of course now needs to be translated, so I updated the .po files (and added German translations for the two flavors of German). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:45:16 -07:00
msgid "backplate weight"
msgstr "Rückenplatten-Gewicht"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: dive.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 09:42:59 +09:00
msgid "bar"
msgstr "bar"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:827
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "belt"
msgstr "Gürtel"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:150
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "bookmark"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Markierung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:149
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "ceiling"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Minimaltiefe"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:152
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "ceiling (safety stop)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Minimaltiefe (Sicherheitsstopp)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:830
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "clip-on"
msgstr "clip-on"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: dive.c:91 planner.c:890
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 09:32:09 -07:00
msgid "cuft"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "cu.ft."
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 09:32:09 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:384
msgid "data"
msgstr ""
#: libdivecomputer.c:149
#, fuzzy
msgid "deco stop"
msgstr "tiefer Stopp"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:152
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "deepstop"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "tiefer Stopp"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:405
msgid "divelog entry id"
msgstr ""
#: uemis-downloader.c:407
msgid "divespot data id"
msgstr ""
#: libdivecomputer.c:152
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "divetime"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Dauer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:589
msgid "drysuit"
msgstr ""
#: planner.c:727
#, fuzzy
msgid "ean"
msgstr "Jan"
#: statistics.c:678
#, c-format
msgid "for all dives"
msgstr ""
#: statistics.c:674
#, fuzzy, c-format
msgid "for dive #%d"
msgstr "Tauchgang #%d - "
#: statistics.c:633
#, c-format
msgid "for dives #"
msgstr ""
#: statistics.c:676
#, fuzzy, c-format
msgid "for selected dive"
msgstr "Nur ausgewählte Tauchgänge drucken"
#: statistics.c:640
#, fuzzy, c-format
msgid "for selected dives"
msgstr "Nur ausgewählte Tauchgänge drucken"
#: dive.c:117 divelist.c:1418 info.c:1078 planner.c:831
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "ft"
msgstr "ft"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:590
msgid "full suit"
msgstr ""
#: libdivecomputer.c:151 libdivecomputer.c:154
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "gaschange"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Flaschenwechsel"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:153
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "heading"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Richtung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:826
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "integrated"
msgstr "integriert"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:171
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "invalid event number"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "ungültige Ereignisnummer"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:590
msgid "jacket"
msgstr ""
#: dive.c:141 equipment.c:1004 gtk-gui.c:649
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "kg"
msgstr "kg"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: dive.c:86
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 09:32:09 -07:00
msgid "l"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "l"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 09:32:09 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: dive.c:137 divelist.c:1421 equipment.c:1006 gtk-gui.c:650
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "lbs"
msgstr "US Pfund"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:590
msgid "long john"
msgstr ""
#: dive.c:112 info.c:1078
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 09:32:09 -07:00
msgid "m"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "m"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 09:32:09 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:800
msgid "max ppO2"
msgstr ""
#: divelist.c:1427 gtk-gui.c:727
msgid "maxCNS"
msgstr ""
#: libdivecomputer.c:153
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "maxdepth"
msgstr "Max. Tiefe"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:591
msgid "membrane"
msgstr ""
#: divelist.c:1419 planner.c:896
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "min"
msgstr "min"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:629
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
#, c-format
msgid "model=%u (0x%08x), firmware=%u (0x%08x), serial=%u (0x%08x)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "model=%u (0x%08x), firmware=%u (0x%08x), serial=%u (0x%08x)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:409
#, fuzzy
msgid "more data dive id"
msgstr "mehr als %d Tage"
#: statistics.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 09:42:59 +09:00
#, c-format
msgid "more than %d days"
msgstr "mehr als %d Tage"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:154
msgid "non stop time"
msgstr ""
#: libdivecomputer.c:149
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "none"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "keine"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:783
msgid "pHe threshold"
msgstr ""
#: gtk-gui.c:765
#, c-format
msgid "pN%s threshold"
msgstr ""
#: gtk-gui.c:746
#, c-format
msgid "pO%s threshold"
msgstr ""
#: dive.c:42
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 09:32:09 -07:00
msgid "pascal"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "Pa"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 09:32:09 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: dive.c:50
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 09:32:09 -07:00
msgid "psi"
More improvements for German translation Based on feedback by German divers (Flasche instead of Tank) and Wikipedia for the official abbreviations of the various units. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 19:34:28 -07:00
msgstr "psi"
Update .po files for recent changes After Lubomir submitted the last set of localization fixes (ec1e1bf30c4f "info.c: set units for translation in the depth box" and 5e463168d2bb "dive.c: set some of units for localization") I apparently forgot to update all the .po files. This should NOT require any extra translation work unless in your target language the units are indeed replaced with something else. Otherwise the empty string "" simply triggers gettext to go with the original text. But after reading through the diff (boy do I know how to have fun) it appears that this caught and (I think) correctly fixed a mistake in the Finnish translation where an incorrect msgid had been used. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-18 09:32:09 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:149
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "rbt"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "rbt"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:153
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "rgbm"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "rgbm"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:150
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "safety stop"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Sicherheitsstopp"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:151
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "safety stop (mandatory)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Sicherheitsstopp (verpflichtend)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:151
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "safety stop (voluntary)"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Sicherheitsstopp (freiwillig)"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:589
msgid "semidry"
msgstr ""
#: uemis-downloader.c:590
msgid "shorty"
msgstr ""
#: libdivecomputer.c:150
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "surface"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Oberfläche"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:154
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "tissue level warning"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Warnung auf Gewebe-Ebene"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Hopefully the last update to the po files before the release This one breaks with my preference to separate generated changes from content changes - I wanted to get the new comment next to the translator-credits text that I added to every .po file. This way the people who worked on these translations at least get shown in the About box. But a simple grep on the diff will show you that this is indeed the only set of changes that I made. git diff HEAD^ | grep ^+ | grep -v -e^+# -e^+++ -ePOT-Creation Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 20:59:43 -07:00
#. ++GETTEXT the term translator-credits is magic - list the names of the tranlators here
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: gtk-gui.c:1062
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:41:41 -07:00
msgid "translator-credits"
Updates for the two German translations Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:46:15 -07:00
msgstr "Dirk Hohndel"
Update the po files NO other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 22:41:41 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:150
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "transmitter"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Sender"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:1345 equipment.c:1365
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "unkn"
msgstr "unbk"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: libdivecomputer.c:152 print.c:317 statistics.c:563 statistics.c:584
#: uemis-downloader.c:133
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "unknown"
msgstr "unbekannt"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:540
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "unspecified"
msgstr "nicht angegeben"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:590
msgid "vest"
msgstr ""
#: libdivecomputer.c:150
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "violation"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Verletzung"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: equipment.c:1481
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 09:42:59 +09:00
msgid "weight"
msgstr "Gewicht"
Improve translations - fix two missing strings in equipment.c (thanks to Tommi Saviranta for pointing this out) - add context for the translations of the Yearly/monthly statistics. The code for this ended up being incredibly ugly, but the gettext infrastructure really clashed with the way this is implemented. What I have now at least works (tested with the German translation) - merge the new strings into all the po files. The non-German translations need to be updated. Make sure you remove the "# , fuzzy" lines or the current Makefile will ignore those additions. - some minor cleanup of the po files (many listed the wrong language, all of them copied my incorrect use of PACKAGE (instead of saying "Subsurface"). Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-14 20:43:32 -07:00
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#: uemis-downloader.c:589
msgid "wetsuit"
msgstr ""
#: libdivecomputer.c:149
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
msgid "workload"
Update German translations This adds all the new terms from libdivecomputer.c Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:42:20 -07:00
msgstr "Arbeit"
Updated po files based on the previous commit NO changes beyond running xgettext and msgmerge Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-20 14:22:29 -07:00
Yet again, new .po files with no other changes Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-21 00:50:45 -07:00
#~ msgid "About"
#~ msgstr "Info"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#~ msgid "Automatically group dives in trips"
#~ msgstr "Automatisch die Tauchgänge gruppieren"
#~ msgid "Delete"
#~ msgstr "Löschen"
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-14 20:43:32 -07:00
#~ msgctxt "Depth"
#~ msgid ""
#~ "Depth\n"
#~ "Average"
#~ msgstr ""
#~ "Tiefe\n"
#~ "Ø"
#~ msgctxt "Duration"
#~ msgid ""
#~ "Duration\n"
#~ "Total"
#~ msgstr ""
#~ "Dauer\n"
#~ "Gesamt"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#~ msgid "Pretty print"
#~ msgstr "Schön drucken"
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-14 20:43:32 -07:00
#~ 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"
#~ "Ø"
Updated PO files in preparation of 3.0 release Translators, please start your engines... Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-02-01 18:08:13 +11:00
#~ msgid "deco"
#~ msgstr "Deko"
Reference in a new issue Copy permalink