{"thread":{"id":"9108","subject":"Re: [PATCH] Internationalization of git-gui","startedAt":"2007-07-19T17:33:57Z","lastAt":"2007-07-24T14:57:16Z","messageCount":48,"participants":["Brett Schwarz","Shawn O. Pearce","Christian Stimming","David Kastrup","Johannes Schindelin","Simon 'corecode' Schubert","Junio C Hamano","Edgar Toernig"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"47881","messageId":"622391.43998.qm@web38909.mail.mud.yahoo.com","threadId":"9108","inReplyTo":null,"subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Brett Schwarz","fromEmail":"brett_schwarz@yahoo.com","sentAt":"2007-07-19T17:33:57Z","receivedAt":"2007-07-19T17:33:57Z","isPatch":true,"sender":{"key":"brett_schwarz@yahoo.com","avatar":null},"body":"This is a good idea. However, I assume the _ proc is just sugar. It might be better to follow a more \"standard\" way for this, and just import the msgcat namespace, and then you can just use [mc]. For example:\n\npackage require msgcat\nnamespace import ::msgcat::*\n .\n .\n .\n.mbar add cascade -label [mc Repository] -menu .mbar.repository\n\nAlso, if the message catalogs are in a common location, then it might be worth looking into having gitk utilize these msg catalogs as well.\n\nThanks,\n --brett\n\n\np.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able to convert -text and -label switches to use msgcat...it might be worth looking into, instead of manually editing git-gui/gitk\n\n\n----- Original Message ----\nFrom: Christian Stimming \nTo: git@vger.kernel.org\nSent: Thursday, July 19, 2007 3:56:57 AM\nSubject: [PATCH] Internationalization of git-gui\n\nThis is an initial patch of how internationalization (i18n) in git \ncould be done, starting with the git-gui application (because I need \nthat one in German to convince my workplace of switching to git).\n\nDoes this implementation look okay? If yes, I'd happily i18n'ize the \nrest of git-gui and provide a full German translation as well.\n\nThanks,\n\nChristian Stimming\n\n\n\n\n\n \n____________________________________________________________________________________\nSick sense of humor? Visit Yahoo! TV's \nComedy with an Edge to see what's on, when. \nhttp://tv.yahoo.com/collections/222\n"},{"id":"47924","messageId":"20070720050455.GN32566@spearce.org","threadId":"9108","inReplyTo":"622391.43998.qm@web38909.mail.mud.yahoo.com","subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-20T05:04:56Z","receivedAt":"2007-07-20T05:04:56Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brett Schwarz wrote:\n> This is a good idea. However, I assume the _ proc is just sugar. It\n> might be better to follow a more \"standard\" way for this, and just\n> import the msgcat namespace, and then you can just use [mc]. For\n> example:\n> \n> package require msgcat\n> namespace import ::msgcat::*\n> .\n> .\n> .\n> .mbar add cascade -label [mc Repository] -menu .mbar.repository\n\nNot just better, I'd prefer it. The proc name \"_\" is cute but\nis just too darn short. I would much prefer to use \"mc\" and just\nsay that \"mc\" in all of git-gui's namespaces is reserved for the\nmessage catalog, much as \"cb\" is already reserved for setting up\ncallbacks for Tcl/Tk event handlers.\n\n-- \nShawn.\n"},{"id":"47956","messageId":"20070720105602.7dcm241ts0k0ww88@webmail.tu-harburg.de","threadId":"9108","inReplyTo":"20070720050455.GN32566@spearce.org","subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-20T08:56:02Z","receivedAt":"2007-07-20T08:56:02Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Quoting \"Shawn O. Pearce\" :\n> Brett Schwarz wrote:\n>> This is a good idea. However, I assume the _ proc is just sugar. It\n>> might be better to follow a more \"standard\" way for this, and just\n>> import the msgcat namespace, and then you can just use [mc].\n>>\n>> package require msgcat\n>> namespace import ::msgcat::*\n>> .\n>> .\n>> .mbar add cascade -label [mc Repository] -menu .mbar.repository\n>\n> Not just better, I'd prefer it. The proc name \"_\" is cute but\n> is just too darn short. I would much prefer to use \"mc\" and just\n> say that \"mc\" in all of git-gui's namespaces is reserved for the\n> message catalog\n\nI used (and prefer) \"_\" because that's the standard function name for \ni18n'd strings when using gettext (talking about a \"standard\" way). In \nthat case the convention from C simply carries over to tcl/tk, and \nprogrammers who have worked with gettext in C before, which uses \n_(\"some message\"), directly apply what they already know. [mc ..], on \nthe other hand, would be a tcl-only function name which doesn't give \ntoo much of a hint of what this function does, except for those \nprogrammers who happen to know that tcl's translation is done by a \npackage called msgcat. One might rather consider something like [tr \n...], for \"translate\", or even [i18n ...].\n\nThat being said, I'm rather agnostic on which proc name you really \nprefer. Just pick one.\n\nBeing a newcomer on this list, could you please explain to me how to \nproceed with the i18n patches so far? Do you want to have patches \nsubmitted after some further changes (which ones?) and/or in different \nformats? Do you prefer to have all changes in a smaller number of \ncommit rather than split the way I did before? Should I wait for some \nmore days/weeks/whatever until you or particular other developers have \nreviewed the patches? Thanks.\n\nChristian\n"},{"id":"47955","messageId":"20070720110354.so2v2d5ysc040sss@webmail.tu-harburg.de","threadId":"9108","inReplyTo":"622391.43998.qm@web38909.mail.mud.yahoo.com","subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-20T09:03:54Z","receivedAt":"2007-07-20T09:03:54Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Quoting Brett Schwarz :\n> Also, if the message catalogs are in a common location, then it \n> might be worth looking into having gitk utilize these msg catalogs \n> as well.\n\nYou mean you suggest to re-use existing msg catalogs in addition to \nones that are created on our own? Well, from the i18n coordination \nwork in another project (gnucash) I wouldn't expect any noticable \nbenefit from doing so. The re-usable parts of translations are rather \nlimited, basically limited to the standard menu entries and some more \nsingle-word strings (Yes/No/Cancel...). But even then re-using other \ntranslations might already decrease the quality of your own \ntranslation, because other translators of packages might already have \nchosen a different translation for e.g. \"Cancel\". For that reason I \nstrongly suggest using one single msg catalog for one single project, \nso that the translator is even able to make sure each word is \ntranslated into the same translation throughout the project.\n\n(I also strongly suggest creating and translating a glossary of the \nimportant terms before starting to translate the msg catalog itself, \nbut that's a different issue.)\n\n> p.s. the frink tool (http://wiki.tcl.tk/2611) is supposed to be able \n> to convert -text and -label switches to use msgcat...it might be \n> worth looking into, instead of manually editing git-gui/gitk\n\nThanks for the pointer. However, the -text and -label switches can be \nfound and edited rather easily by keyboard macros and such. More \nimportant than this are some changes that are necessary in order to \nobtain strings that are actually translatable, such as\n\n-\t.mbar.apple add command -label \"About [appname]\" \\\n+\t.mbar.apple add command -label [format [_ \"About %s\"] [appname]] \\\n\nand you will agree those can only be done manually anyway.\n\nChristian\n"},{"id":"48003","messageId":"20070721021717.GS32566@spearce.org","threadId":"9108","inReplyTo":"20070720105602.7dcm241ts0k0ww88@webmail.tu-harburg.de","subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-21T02:17:17Z","receivedAt":"2007-07-21T02:17:17Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian Stimming wrote:\n> I used (and prefer) \"_\" because that's the standard function name for \n> i18n'd strings when using gettext (talking about a \"standard\" way).\n\nI thought about this today. I almost want to use _, e.g:\n\n proc _ {args} {\n return [eval mc $args]\n }\n\nFor the translation, but I don't think its worth the CPU cycles in\nTcl to eval mc via _ every time we need a string when it only is\nsaving us one keystroke on a function name, *and* we are breaking\ntradition with Tcl.\n\nSo when in Rome, wear a toga. Or in this case, use [mc ...].\n\n> Being a newcomer on this list, could you please explain to me how to \n> proceed with the i18n patches so far?\n\nSure.\n\n> Do you want to have patches \n> submitted after some further changes (which ones?)\n\nYes. Here's a few to get started with and that are really obvious.\nSome I'm just asking for more information on.\n\n - Import msgcat::mc and use [mc] instead of [_].\n\n - Please combine the second and third patches into a single change.\n There is no reason to switch to [mc {}] only to switch to [mc \"\"].\n\n - Please use mc's formatting support, rather than [format].\n Its shorter code.\n\n - Don't bother trying to translate the strings \"Tools\" (for the\n Tools menu) or \"Migrate\" (for its only menu option). This block\n of code doesn't even belong in git-gui. Its for my day-job and\n is a custom hack that I need to strip out and carry as a local\n patch there, rather than in the public distribution.\n\n - In our Makefile we do the looping in GNU make using its\n $(foreach) operator, rather than using the shell's for builtin.\n In other words, can we have the catalog target look more like the\n install target?\n\n - Can ALL_LINGUAS be automatically built from the directory\n contents of the po/ directory?\n\n - Can we define a dist rule for the maintainer to build the catalog\n files, so the maintainer can convert the .po -> .msg for Tcl and\n the user doesn't need the GNU tools installed to build git-gui?\n\n\n> and/or in different \n> formats?\n\nPlease send one patch per email message, inline and not attached.\nThis way they are easy to review, respond to and comment on.\n\n> Do you prefer to have all changes in a smaller number of \n> commit rather than split the way I did before?\n\nNo, this series looks reasonably fine to me structurally.\n\nDid you base the patches on git.git's git-gui/ subdirectory, or\ndid you base them on the git-gui.git repository? Technically all\npatches for git-gui should be against the git-gui repository on\nrepo.or.cz, as git-gui is its own project. Periodic stable snapshots\nare imported into git.git under the git-gui/ subdirectory, for the\nease of distribution with core git.\n\nDscho recently created a fork of git-gui.git here:\n\n http://repo.or.cz/w/git-gui/git-gui-i18n.git\n\nand added your patch series into it. But I'd like to see some\ncleanups before it merges in, and I want to hold off on actually\napplying it into git-gui 0.8.0 is released, which should be Real\nSoon Now as I'm trying to make it into git 1.5.3, which is coming\nEven Sooner Than I'd Hoped. ;-)\n\n> Should I wait for some \n> more days/weeks/whatever until you or particular other developers have \n> reviewed the patches? Thanks.\n\nI think we're settled on using [mc]. I'm fine with the *.po ->\n*.msg thing, especially if the maintainer can produce them and\npackage the *.msg files in the release tarball, so that the enduser\ndoesn't need to worry about msgfmt working.\n\n-- \nShawn.\n"},{"id":"48023","messageId":"200707210951.00210.stimming@tuhh.de","threadId":"9108","inReplyTo":"20070721021717.GS32566@spearce.org","subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T07:50:58Z","receivedAt":"2007-07-21T07:50:58Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Thanks for the detailed feedback.\n\nAm Samstag, 21. Juli 2007 04:17 schrieb Shawn O. Pearce:\n> Christian Stimming wrote:\n> > I used (and prefer) \"_\" because that's the standard function name for\n> > i18n'd strings when using gettext (talking about a \"standard\" way).\n>\n> but I don't think its worth the CPU cycles in\n> Tcl to eval mc via _ every time we need a string when it only is\n> saving us one keystroke on a function name, \n\nThe actual lookup of the string in the translation catalog far outweighs the \ndiscussion of one extra function evaluation, but if that's what you prefer -\n\n> *and* we are breaking tradition with Tcl.\n>\n> So when in Rome, wear a toga. Or in this case, use [mc ...].\n\nOk.\n\n> > Do you want to have patches\n> > submitted after some further changes (which ones?)\n>\n> Yes. Here's a few to get started with and that are really obvious.\n> Some I'm just asking for more information on.\n>\n> - Import msgcat::mc and use [mc] instead of [_].\n\nWill do.\n\n> - Please combine the second and third patches into a single change.\n> There is no reason to switch to [mc {}] only to switch to [mc \"\"].\n\nWill do.\n\n> - Please use mc's formatting support, rather than [format].\n> Its shorter code.\n\nDidn't know about that (you know, C gettext doesn't have that), and I'll have \nto check whether this might confuse xgettext on string extraction, but will \nprobably be done.\n\n> - Don't bother trying to translate the strings \"Tools\" (for the\n> Tools menu) or \"Migrate\" (for its only menu option). This block\n> of code doesn't even belong in git-gui. Its for my day-job and\n> is a custom hack that I need to strip out and carry as a local\n> patch there, rather than in the public distribution.\n\nErr... from looking at the code, it's not quite clear to me whether any code \nparts like these are not publicly shown to the user. For that reason I rather \ntranslated everything that was currently available in the file. But I'll \nhappily remove this from the patch.\n\n> - In our Makefile we do the looping in GNU make using its\n> $(foreach) operator, rather than using the shell's for builtin.\n> In other words, can we have the catalog target look more like the\n> install target?\n\nSure. I did it this way because I'm more used to the shell syntax, but I'll \nchange that.\n\n> - Can ALL_LINGUAS be automatically built from the directory\n> contents of the po/ directory?\n\nYes. I used this one because this variable always appears in gettext's \nautoconf infrastructure, but it's not required here. Will remove it.\n\n> - Can we define a dist rule for the maintainer to build the catalog\n> files, so the maintainer can convert the .po -> .msg for Tcl and\n> the user doesn't need the GNU tools installed to build git-gui?\n\nYes, I'll try to add that, but I'd need further feedback and testing whether \nit actually works.\n\n> > and/or in different\n> > formats?\n>\n> Please send one patch per email message, inline and not attached.\n> This way they are easy to review, respond to and comment on.\n\nI'll try to do that, but at the workplace where I work on this issue I'm \nforced to use a webmailer and I have to check whether this leaves the patches \nintact.\n\n> > Do you prefer to have all changes in a smaller number of\n> > commit rather than split the way I did before?\n>\n> No, this series looks reasonably fine to me structurally.\n>\n> Did you base the patches on git.git's git-gui/ subdirectory, \n\nYes.\n\n> or \n> did you base them on the git-gui.git repository? Technically all\n> patches for git-gui should be against the git-gui repository on\n> repo.or.cz, as git-gui is its own project. \n\nWill do.\n\n> Dscho recently created a fork of git-gui.git here:\n>\n> http://repo.or.cz/w/git-gui/git-gui-i18n.git\n>\n> and added your patch series into it. But I'd like to see some\n> cleanups before it merges in, and I want to hold off on actually\n> applying it into git-gui 0.8.0 is released, \n\nWas this meant to say \"hold off until git-gui 0.8.0 is released\"? Sure, no \nproblem.\n\nI'll submit an updated set of patches by beginning of next week. Thank you \nvery much for the feedback.\n\nChristian\n"},{"id":"48024","messageId":"20070721080338.GT32566@spearce.org","threadId":"9108","inReplyTo":"200707210951.00210.stimming@tuhh.de","subject":"Re: [PATCH] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-21T08:03:38Z","receivedAt":"2007-07-21T08:03:38Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian Stimming wrote:\n> Thanks for the detailed feedback.\n\nThanks for working on this! Its something I knew we need to do,\nbut hadn't brought myself to do, because I speak English, and pretty\nmuch only English. Unless Tcl counts. ;-)\n \n> Am Samstag, 21. Juli 2007 04:17 schrieb Shawn O. Pearce:\n> >\n> > Please send one patch per email message, inline and not attached.\n> > This way they are easy to review, respond to and comment on.\n> \n> I'll try to do that, but at the workplace where I work on this issue I'm \n> forced to use a webmailer and I have to check whether this leaves the patches \n> intact.\n\nCan you push to the mob branch on repo.or.cz? Or setup your own\ngit-gui fork repository there? Or someplace? If so you can still\ncopy and paste the message into email for quick review and comment,\nbut I can actually pull the Git objects from a repository, and I\nknow Git won't corrupt things.\n \n> > Dscho recently created a fork of git-gui.git here:\n> >\n> > http://repo.or.cz/w/git-gui/git-gui-i18n.git\n> >\n> > and added your patch series into it. But I'd like to see some\n> > cleanups before it merges in, and I want to hold off on actually\n> > applying it into git-gui 0.8.0 is released, \n> \n> Was this meant to say \"hold off until git-gui 0.8.0 is released\"? Sure, no \n> problem.\n\nMore or less. I'm interested in this series, so I'm happy to get the\npatches. But I won't put them into 0.8.0, as I think it is too late\nin the development period. Especially for a build system change.\nI've had too many bugs because of changes to the Makefile in prior\nversions of git-gui. But I am hoping that they will be among the\nvery first things applied after I tag 0.8.0 and start the 0.9.0\ndevelopment cycle. :-)\n \n> I'll submit an updated set of patches by beginning of next week. Thank you \n> very much for the feedback.\n\nThanks.\n\n-- \nShawn.\n"},{"id":"48032","messageId":"200707211433.29318.stimming@tuhh.de","threadId":"9108","inReplyTo":"20070721080338.GT32566@spearce.org","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T12:33:28Z","receivedAt":"2007-07-21T12:33:28Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":">From 18d783abd85e074c302c5e7979dfb242b3c6c386 Mon Sep 17 00:00:00 2001\nFrom: Christian Stimming \nDate: Sat, 21 Jul 2007 13:51:48 +0200\nSubject: [PATCH] Initialize msgcat (gettext).\n\nUse [mc ...] as function name for translating user messages.\n\nSigned-off-by: Christian Stimming \n---\n\nThis patch starts over from before the first i18n patch has been applied and \ntakes into account all discussion with Shawn. Currently I don't quite know \nhow to apply these patches to the \"mob\" branch because one would have\nto first revert those patches from me that have been applied there... Thanks.\n\n git-gui.sh | 6 ++++++\n 1 files changed, 6 insertions(+), 0 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex c5ff7c8..0c5ca46 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -108,6 +108,12 @@ if {$idx ne {}} {\n }\n unset -nocomplain oguirel idx fd\n \n+## Internationalization (i18n) through msgcat and gettext. See\n+## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html\n+package require msgcat\n+::msgcat::mcload [file join $oguilib msgs]\n+namespace import ::msgcat::mc\n+\n ######################################################################\n ##\n ## read only globals\n-- \n1.5.2\n"},{"id":"48033","messageId":"200707211434.56622.stimming@tuhh.de","threadId":"9108","inReplyTo":"200707211433.29318.stimming@tuhh.de","subject":"Re: [PATCH 2/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T12:34:55Z","receivedAt":"2007-07-21T12:34:55Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":">From d2d2dde44790c3d239d69d7250e9949b6ff002c2 Mon Sep 17 00:00:00 2001\nFrom: Christian Stimming \nDate: Sat, 21 Jul 2007 14:21:34 +0200\nSubject: [PATCH] Mark strings for translation.\n\nThe procedure [mc ...] will translate the strings through msgcat.\nStrings must be enclosed in quotes, not in braces, because otherwise\nxgettext cannot extract them properly, although on the Tcl side both\ndelimiters would work fine.\n\nSigned-off-by: Christian Stimming \n---\n\nHere I marked much more strings than in the previous patch, and as discussed\nthe procedure [mc ...] is used for translation. Actually I think this pretty much \ncaught all occurrences of user-visible strings in *this* file; there will be many\nmore strings in all the other files, of course.\n\n git-gui.sh | 170 ++++++++++++++++++++++++++++++------------------------------\n 1 files changed, 85 insertions(+), 85 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 0c5ca46..95dac55 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -1653,18 +1653,18 @@ set ui_comm {}\n # -- Menu Bar\n #\n menu .mbar -tearoff 0\n-.mbar add cascade -label Repository -menu .mbar.repository\n-.mbar add cascade -label Edit -menu .mbar.edit\n+.mbar add cascade -label [mc Repository] -menu .mbar.repository\n+.mbar add cascade -label [mc Edit] -menu .mbar.edit\n if {[is_enabled branch]} {\n-\t.mbar add cascade -label Branch -menu .mbar.branch\n+\t.mbar add cascade -label [mc Branch] -menu .mbar.branch\n }\n if {[is_enabled multicommit] || [is_enabled singlecommit]} {\n-\t.mbar add cascade -label Commit -menu .mbar.commit\n+\t.mbar add cascade -label [mc Commit] -menu .mbar.commit\n }\n if {[is_enabled transport]} {\n-\t.mbar add cascade -label Merge -menu .mbar.merge\n-\t.mbar add cascade -label Fetch -menu .mbar.fetch\n-\t.mbar add cascade -label Push -menu .mbar.push\n+\t.mbar add cascade -label [mc Merge] -menu .mbar.merge\n+\t.mbar add cascade -label [mc Fetch] -menu .mbar.fetch\n+\t.mbar add cascade -label [mc Push] -menu .mbar.push\n }\n . configure -menu .mbar\n \n@@ -1673,7 +1673,7 @@ if {[is_enabled transport]} {\n menu .mbar.repository\n \n .mbar.repository add command \\\n-\t-label {Browse Current Branch's Files} \\\n+\t-label [mc \"Browse Current Branch's Files\"] \\\n \t-command {browser::new $current_branch}\n trace add variable current_branch write \".mbar.repository entryconf [.mbar.repository index last] -label \\\"Browse \\$current_branch's Files\\\" ;#\"\n .mbar.repository add command \\\n@@ -1682,69 +1682,69 @@ trace add variable current_branch write \".mbar.repository entryconf [.mbar.repos\n .mbar.repository add separator\n \n .mbar.repository add command \\\n-\t-label {Visualize Current Branch's History} \\\n+\t-label [mc \"Visualize Current Branch's History\"] \\\n \t-command {do_gitk $current_branch}\n trace add variable current_branch write \".mbar.repository entryconf [.mbar.repository index last] -label \\\"Visualize \\$current_branch's History\\\" ;#\"\n .mbar.repository add command \\\n-\t-label {Visualize All Branch History} \\\n+\t-label [mc \"Visualize All Branch History\"] \\\n \t-command {do_gitk --all}\n .mbar.repository add separator\n \n if {[is_enabled multicommit]} {\n-\t.mbar.repository add command -label {Database Statistics} \\\n+\t.mbar.repository add command -label [mc \"Database Statistics\"] \\\n \t\t-command do_stats\n \n-\t.mbar.repository add command -label {Compress Database} \\\n+\t.mbar.repository add command -label [mc \"Compress Database\"] \\\n \t\t-command do_gc\n \n-\t.mbar.repository add command -label {Verify Database} \\\n+\t.mbar.repository add command -label [mc \"Verify Database\"] \\\n \t\t-command do_fsck_objects\n \n \t.mbar.repository add separator\n \n \tif {[is_Cygwin]} {\n \t\t.mbar.repository add command \\\n-\t\t\t-label {Create Desktop Icon} \\\n+\t\t\t-label [mc \"Create Desktop Icon\"] \\\n \t\t\t-command do_cygwin_shortcut\n \t} elseif {[is_Windows]} {\n \t\t.mbar.repository add command \\\n-\t\t\t-label {Create Desktop Icon} \\\n+\t\t\t-label [mc \"Create Desktop Icon\"] \\\n \t\t\t-command do_windows_shortcut\n \t} elseif {[is_MacOSX]} {\n \t\t.mbar.repository add command \\\n-\t\t\t-label {Create Desktop Icon} \\\n+\t\t\t-label [mc \"Create Desktop Icon\"] \\\n \t\t\t-command do_macosx_app\n \t}\n }\n \n-.mbar.repository add command -label Quit \\\n+.mbar.repository add command -label [mc Quit] \\\n \t-command do_quit \\\n \t-accelerator $M1T-Q\n \n # -- Edit Menu\n #\n menu .mbar.edit\n-.mbar.edit add command -label Undo \\\n+.mbar.edit add command -label [mc Undo] \\\n \t-command {catch {[focus] edit undo}} \\\n \t-accelerator $M1T-Z\n-.mbar.edit add command -label Redo \\\n+.mbar.edit add command -label [mc Redo] \\\n \t-command {catch {[focus] edit redo}} \\\n \t-accelerator $M1T-Y\n .mbar.edit add separator\n-.mbar.edit add command -label Cut \\\n+.mbar.edit add command -label [mc Cut] \\\n \t-command {catch {tk_textCut [focus]}} \\\n \t-accelerator $M1T-X\n-.mbar.edit add command -label Copy \\\n+.mbar.edit add command -label [mc Copy] \\\n \t-command {catch {tk_textCopy [focus]}} \\\n \t-accelerator $M1T-C\n-.mbar.edit add command -label Paste \\\n+.mbar.edit add command -label [mc Paste] \\\n \t-command {catch {tk_textPaste [focus]; [focus] see insert}} \\\n \t-accelerator $M1T-V\n-.mbar.edit add command -label Delete \\\n+.mbar.edit add command -label [mc Delete] \\\n \t-command {catch {[focus] delete sel.first sel.last}} \\\n \t-accelerator Del\n .mbar.edit add separator\n-.mbar.edit add command -label {Select All} \\\n+.mbar.edit add command -label [mc \"Select All\"] \\\n \t-command {catch {[focus] tag add sel 0.0 end}} \\\n \t-accelerator $M1T-A\n \n@@ -1753,29 +1753,29 @@ menu .mbar.edit\n if {[is_enabled branch]} {\n \tmenu .mbar.branch\n \n-\t.mbar.branch add command -label {Create...} \\\n+\t.mbar.branch add command -label [mc \"Create...\"] \\\n \t\t-command branch_create::dialog \\\n \t\t-accelerator $M1T-N\n \tlappend disable_on_lock [list .mbar.branch entryconf \\\n \t\t[.mbar.branch index last] -state]\n \n-\t.mbar.branch add command -label {Checkout...} \\\n+\t.mbar.branch add command -label [mc \"Checkout...\"] \\\n \t\t-command branch_checkout::dialog \\\n \t\t-accelerator $M1T-O\n \tlappend disable_on_lock [list .mbar.branch entryconf \\\n \t\t[.mbar.branch index last] -state]\n \n-\t.mbar.branch add command -label {Rename...} \\\n+\t.mbar.branch add command -label [mc \"Rename...\"] \\\n \t\t-command branch_rename::dialog\n \tlappend disable_on_lock [list .mbar.branch entryconf \\\n \t\t[.mbar.branch index last] -state]\n \n-\t.mbar.branch add command -label {Delete...} \\\n+\t.mbar.branch add command -label [mc \"Delete...\"] \\\n \t\t-command branch_delete::dialog\n \tlappend disable_on_lock [list .mbar.branch entryconf \\\n \t\t[.mbar.branch index last] -state]\n \n-\t.mbar.branch add command -label {Reset...} \\\n+\t.mbar.branch add command -label [mc \"Reset...\"] \\\n \t\t-command merge::reset_hard\n \tlappend disable_on_lock [list .mbar.branch entryconf \\\n \t\t[.mbar.branch index last] -state]\n@@ -1787,7 +1787,7 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {\n \tmenu .mbar.commit\n \n \t.mbar.commit add radiobutton \\\n-\t\t-label {New Commit} \\\n+\t\t-label [mc \"New Commit\"] \\\n \t\t-command do_select_commit_type \\\n \t\t-variable selected_commit_type \\\n \t\t-value new\n@@ -1795,7 +1795,7 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {\n \t\t[list .mbar.commit entryconf [.mbar.commit index last] -state]\n \n \t.mbar.commit add radiobutton \\\n-\t\t-label {Amend Last Commit} \\\n+\t\t-label [mc \"Amend Last Commit\"] \\\n \t\t-command do_select_commit_type \\\n \t\t-variable selected_commit_type \\\n \t\t-value amend\n@@ -1804,40 +1804,40 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {\n \n \t.mbar.commit add separator\n \n-\t.mbar.commit add command -label Rescan \\\n+\t.mbar.commit add command -label [mc Rescan] \\\n \t\t-command do_rescan \\\n \t\t-accelerator F5\n \tlappend disable_on_lock \\\n \t\t[list .mbar.commit entryconf [.mbar.commit index last] -state]\n \n-\t.mbar.commit add command -label {Add To Commit} \\\n+\t.mbar.commit add command -label [mc \"Add To Commit\"] \\\n \t\t-command do_add_selection\n \tlappend disable_on_lock \\\n \t\t[list .mbar.commit entryconf [.mbar.commit index last] -state]\n \n-\t.mbar.commit add command -label {Add Existing To Commit} \\\n+\t.mbar.commit add command -label [mc \"Add Existing To Commit\"] \\\n \t\t-command do_add_all \\\n \t\t-accelerator $M1T-I\n \tlappend disable_on_lock \\\n \t\t[list .mbar.commit entryconf [.mbar.commit index last] -state]\n \n-\t.mbar.commit add command -label {Unstage From Commit} \\\n+\t.mbar.commit add command -label [mc \"Unstage From Commit\"] \\\n \t\t-command do_unstage_selection\n \tlappend disable_on_lock \\\n \t\t[list .mbar.commit entryconf [.mbar.commit index last] -state]\n \n-\t.mbar.commit add command -label {Revert Changes} \\\n+\t.mbar.commit add command -label [mc \"Revert Changes\"] \\\n \t\t-command do_revert_selection\n \tlappend disable_on_lock \\\n \t\t[list .mbar.commit entryconf [.mbar.commit index last] -state]\n \n \t.mbar.commit add separator\n \n-\t.mbar.commit add command -label {Sign Off} \\\n+\t.mbar.commit add command -label [mc \"Sign Off\"] \\\n \t\t-command do_signoff \\\n \t\t-accelerator $M1T-S\n \n-\t.mbar.commit add command -label Commit \\\n+\t.mbar.commit add command -label [mc Commit] \\\n \t\t-command do_commit \\\n \t\t-accelerator $M1T-Return\n \tlappend disable_on_lock \\\n@@ -1848,12 +1848,12 @@ if {[is_enabled multicommit] || [is_enabled singlecommit]} {\n #\n if {[is_enabled branch]} {\n \tmenu .mbar.merge\n-\t.mbar.merge add command -label {Local Merge...} \\\n+\t.mbar.merge add command -label [mc \"Local Merge...\"] \\\n \t\t-command merge::dialog \\\n \t\t-accelerator $M1T-M\n \tlappend disable_on_lock \\\n \t\t[list .mbar.merge entryconf [.mbar.merge index last] -state]\n-\t.mbar.merge add command -label {Abort Merge...} \\\n+\t.mbar.merge add command -label [mc \"Abort Merge...\"] \\\n \t\t-command merge::reset_hard\n \tlappend disable_on_lock \\\n \t\t[list .mbar.merge entryconf [.mbar.merge index last] -state]\n@@ -1865,28 +1865,28 @@ if {[is_enabled transport]} {\n \tmenu .mbar.fetch\n \n \tmenu .mbar.push\n-\t.mbar.push add command -label {Push...} \\\n+\t.mbar.push add command -label [mc \"Push...\"] \\\n \t\t-command do_push_anywhere \\\n \t\t-accelerator $M1T-P\n-\t.mbar.push add command -label {Delete...} \\\n+\t.mbar.push add command -label [mc \"Delete...\"] \\\n \t\t-command remote_branch_delete::dialog\n }\n \n if {[is_MacOSX]} {\n \t# -- Apple Menu (Mac OS X only)\n \t#\n-\t.mbar add cascade -label Apple -menu .mbar.apple\n+\t.mbar add cascade -label [mc Apple] -menu .mbar.apple\n \tmenu .mbar.apple\n \n-\t.mbar.apple add command -label \"About [appname]\" \\\n+\t.mbar.apple add command -label [mc \"About %s\" appname] \\\n \t\t-command do_about\n-\t.mbar.apple add command -label \"Options...\" \\\n+\t.mbar.apple add command -label [mc \"Options...\"] \\\n \t\t-command do_options\n } else {\n \t# -- Edit Menu\n \t#\n \t.mbar.edit add separator\n-\t.mbar.edit add command -label {Options...} \\\n+\t.mbar.edit add command -label [mc \"Options...\"] \\\n \t\t-command do_options\n \n \t# -- Tools Menu\n@@ -1921,11 +1921,11 @@ if {[is_MacOSX]} {\n \n # -- Help Menu\n #\n-.mbar add cascade -label Help -menu .mbar.help\n+.mbar add cascade -label [mc Help] -menu .mbar.help\n menu .mbar.help\n \n if {![is_MacOSX]} {\n-\t.mbar.help add command -label \"About [appname]\" \\\n+\t.mbar.help add command -label [mc \"About %s\" appname] \\\n \t\t-command do_about\n }\n \n@@ -1962,7 +1962,7 @@ if {[file isfile $doc_path]} {\n }\n \n if {$browser ne {}} {\n-\t.mbar.help add command -label {Online Documentation} \\\n+\t.mbar.help add command -label [mc \"Online Documentation\"] \\\n \t\t-command [list exec $browser $doc_url &]\n }\n unset browser doc_path doc_url\n@@ -2078,7 +2078,7 @@ frame .branch \\\n \t-borderwidth 1 \\\n \t-relief sunken\n label .branch.l1 \\\n-\t-text {Current Branch:} \\\n+\t-text [mc \"Current Branch:\"] \\\n \t-anchor w \\\n \t-justify left\n label .branch.cb \\\n@@ -2099,7 +2099,7 @@ pack .vpane -anchor n -side top -fill both -expand 1\n # -- Index File List\n #\n frame .vpane.files.index -height 100 -width 200\n-label .vpane.files.index.title -text {Staged Changes (Will Be Committed)} \\\n+label .vpane.files.index.title -text [mc \"Staged Changes (Will Be Committed)\"] \\\n \t-background lightgreen\n text $ui_index -background white -borderwidth 0 \\\n \t-width 20 -height 10 \\\n@@ -2119,7 +2119,7 @@ pack $ui_index -side left -fill both -expand 1\n # -- Working Directory File List\n #\n frame .vpane.files.workdir -height 100 -width 200\n-label .vpane.files.workdir.title -text {Unstaged Changes (Will Not Be Committed)} \\\n+label .vpane.files.workdir.title -text [mc \"Unstaged Changes (Will Not Be Committed)\"] \\\n \t-background lightsalmon\n text $ui_workdir -background white -borderwidth 0 \\\n \t-width 20 -height 10 \\\n@@ -2160,29 +2160,29 @@ label .vpane.lower.commarea.buttons.l -text {} \\\n pack .vpane.lower.commarea.buttons.l -side top -fill x\n pack .vpane.lower.commarea.buttons -side left -fill y\n \n-button .vpane.lower.commarea.buttons.rescan -text {Rescan} \\\n+button .vpane.lower.commarea.buttons.rescan -text [mc Rescan] \\\n \t-command do_rescan\n pack .vpane.lower.commarea.buttons.rescan -side top -fill x\n lappend disable_on_lock \\\n \t{.vpane.lower.commarea.buttons.rescan conf -state}\n \n-button .vpane.lower.commarea.buttons.incall -text {Add Existing} \\\n+button .vpane.lower.commarea.buttons.incall -text [mc \"Add Existing\"] \\\n \t-command do_add_all\n pack .vpane.lower.commarea.buttons.incall -side top -fill x\n lappend disable_on_lock \\\n \t{.vpane.lower.commarea.buttons.incall conf -state}\n \n-button .vpane.lower.commarea.buttons.signoff -text {Sign Off} \\\n+button .vpane.lower.commarea.buttons.signoff -text [mc \"Sign Off\"] \\\n \t-command do_signoff\n pack .vpane.lower.commarea.buttons.signoff -side top -fill x\n \n-button .vpane.lower.commarea.buttons.commit -text {Commit} \\\n+button .vpane.lower.commarea.buttons.commit -text [mc Commit] \\\n \t-command do_commit\n pack .vpane.lower.commarea.buttons.commit -side top -fill x\n lappend disable_on_lock \\\n \t{.vpane.lower.commarea.buttons.commit conf -state}\n \n-button .vpane.lower.commarea.buttons.push -text {Push} \\\n+button .vpane.lower.commarea.buttons.push -text [mc Push] \\\n \t-command do_push_anywhere\n pack .vpane.lower.commarea.buttons.push -side top -fill x\n \n@@ -2193,14 +2193,14 @@ frame .vpane.lower.commarea.buffer.header\n set ui_comm .vpane.lower.commarea.buffer.t\n set ui_coml .vpane.lower.commarea.buffer.header.l\n radiobutton .vpane.lower.commarea.buffer.header.new \\\n-\t-text {New Commit} \\\n+\t-text [mc \"New Commit\"] \\\n \t-command do_select_commit_type \\\n \t-variable selected_commit_type \\\n \t-value new\n lappend disable_on_lock \\\n \t[list .vpane.lower.commarea.buffer.header.new conf -state]\n radiobutton .vpane.lower.commarea.buffer.header.amend \\\n-\t-text {Amend Last Commit} \\\n+\t-text [mc \"Amend Last Commit\"] \\\n \t-command do_select_commit_type \\\n \t-variable selected_commit_type \\\n \t-value amend\n@@ -2212,12 +2212,12 @@ label $ui_coml \\\n proc trace_commit_type {varname args} {\n \tglobal ui_coml commit_type\n \tswitch -glob -- $commit_type {\n-\tinitial {set txt {Initial Commit Message:}}\n-\tamend {set txt {Amended Commit Message:}}\n-\tamend-initial {set txt {Amended Initial Commit Message:}}\n-\tamend-merge {set txt {Amended Merge Commit Message:}}\n-\tmerge {set txt {Merge Commit Message:}}\n-\t* {set txt {Commit Message:}}\n+\tinitial {set txt [mc \"Initial Commit Message:\"]}\n+\tamend {set txt [mc \"Amended Commit Message:\"]}\n+\tamend-initial {set txt [mc \"Amended Initial Commit Message:\"]}\n+\tamend-merge {set txt [mc \"Amended Merge Commit Message:\"]}\n+\tmerge {set txt [mc \"Merge Commit Message:\"]}\n+\t* {set txt [mc \"Commit Message:\"]}\n \t}\n \t$ui_coml conf -text $txt\n }\n@@ -2246,23 +2246,23 @@ pack .vpane.lower.commarea.buffer -side left -fill y\n set ctxm .vpane.lower.commarea.buffer.ctxm\n menu $ctxm -tearoff 0\n $ctxm add command \\\n-\t-label {Cut} \\\n+\t-label [mc Cut] \\\n \t-command {tk_textCut $ui_comm}\n $ctxm add command \\\n-\t-label {Copy} \\\n+\t-label [mc Copy] \\\n \t-command {tk_textCopy $ui_comm}\n $ctxm add command \\\n-\t-label {Paste} \\\n+\t-label [mc Paste] \\\n \t-command {tk_textPaste $ui_comm}\n $ctxm add command \\\n-\t-label {Delete} \\\n+\t-label [mc Delete] \\\n \t-command {$ui_comm delete sel.first sel.last}\n $ctxm add separator\n $ctxm add command \\\n-\t-label {Select All} \\\n+\t-label [mc \"Select All\"] \\\n \t-command {focus $ui_comm;$ui_comm tag add sel 0.0 end}\n $ctxm add command \\\n-\t-label {Copy All} \\\n+\t-label [mc \"Copy All\"] \\\n \t-command {\n \t\t$ui_comm tag add sel 0.0 end\n \t\ttk_textCopy $ui_comm\n@@ -2270,7 +2270,7 @@ $ctxm add command \\\n \t}\n $ctxm add separator\n $ctxm add command \\\n-\t-label {Sign Off} \\\n+\t-label [mc \"Sign Off\"] \\\n \t-command do_signoff\n bind_button3 $ui_comm \"tk_popup $ctxm %X %Y\"\n \n@@ -2320,7 +2320,7 @@ pack .vpane.lower.diff.header.path -fill x\n set ctxm .vpane.lower.diff.header.ctxm\n menu $ctxm -tearoff 0\n $ctxm add command \\\n-\t-label {Copy} \\\n+\t-label [mc Copy] \\\n \t-command {\n \t\tclipboard clear\n \t\tclipboard append \\\n@@ -2388,19 +2388,19 @@ $ui_diff tag raise sel\n set ctxm .vpane.lower.diff.body.ctxm\n menu $ctxm -tearoff 0\n $ctxm add command \\\n-\t-label {Refresh} \\\n+\t-label [mc Refresh] \\\n \t-command reshow_diff\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add command \\\n-\t-label {Copy} \\\n+\t-label [mc Copy] \\\n \t-command {tk_textCopy $ui_diff}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add command \\\n-\t-label {Select All} \\\n+\t-label [mc \"Select All\"] \\\n \t-command {focus $ui_diff;$ui_diff tag add sel 0.0 end}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add command \\\n-\t-label {Copy All} \\\n+\t-label [mc \"Copy All\"] \\\n \t-command {\n \t\t$ui_diff tag add sel 0.0 end\n \t\ttk_textCopy $ui_diff\n@@ -2409,44 +2409,44 @@ $ctxm add command \\\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add separator\n $ctxm add command \\\n-\t-label {Apply/Reverse Hunk} \\\n+\t-label [mc \"Apply/Reverse Hunk\"] \\\n \t-command {apply_hunk $cursorX $cursorY}\n set ui_diff_applyhunk [$ctxm index last]\n lappend diff_actions [list $ctxm entryconf $ui_diff_applyhunk -state]\n $ctxm add separator\n $ctxm add command \\\n-\t-label {Decrease Font Size} \\\n+\t-label [mc \"Decrease Font Size\"] \\\n \t-command {incr_font_size font_diff -1}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add command \\\n-\t-label {Increase Font Size} \\\n+\t-label [mc \"Increase Font Size\"] \\\n \t-command {incr_font_size font_diff 1}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add separator\n $ctxm add command \\\n-\t-label {Show Less Context} \\\n+\t-label [mc \"Show Less Context\"] \\\n \t-command {if {$repo_config(gui.diffcontext) >= 1} {\n \t\tincr repo_config(gui.diffcontext) -1\n \t\treshow_diff\n \t}}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add command \\\n-\t-label {Show More Context} \\\n+\t-label [mc \"Show More Context\"] \\\n \t-command {if {$repo_config(gui.diffcontext) < 99} {\n \t\tincr repo_config(gui.diffcontext)\n \t\treshow_diff\n \t}}\n lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]\n $ctxm add separator\n-$ctxm add command -label {Options...} \\\n+$ctxm add command -label [mc \"Options...\"] \\\n \t-command do_options\n bind_button3 $ui_diff \"\n \tset cursorX %x\n \tset cursorY %y\n \tif {\\$ui_index eq \\$current_diff_side} {\n-\t\t$ctxm entryconf $ui_diff_applyhunk -label {Unstage Hunk From Commit}\n+\t\t$ctxm entryconf $ui_diff_applyhunk -label [mc {Unstage Hunk From Commit}]\n \t} else {\n-\t\t$ctxm entryconf $ui_diff_applyhunk -label {Stage Hunk For Commit}\n+\t\t$ctxm entryconf $ui_diff_applyhunk -label [mc {Stage Hunk For Commit}]\n \t}\n \ttk_popup $ctxm %X %Y\n \"\n-- \n1.5.2\n"},{"id":"48034","messageId":"200707211436.44672.stimming@tuhh.de","threadId":"9108","inReplyTo":"200707211434.56622.stimming@tuhh.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T12:36:44Z","receivedAt":"2007-07-21T12:36:44Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":">From cf68c8b36399d46f63e417e99c6783411213a55a Mon Sep 17 00:00:00 2001\nFrom: Christian Stimming \nDate: Sat, 21 Jul 2007 14:17:07 +0200\nSubject: [PATCH] Makefile rules for translation catalog generation and installation.\n\n\nSigned-off-by: Christian Stimming \n---\nAs discussed I've replaced the shell for() by the GNU make foreach. Also, there \nisn't an ALL_LINGUAS variable anymore; we simply use all *.po files under po/.\n\n Makefile | 19 ++++++++++++++++++-\n 1 files changed, 18 insertions(+), 1 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 1bac6fe..52975a7 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -103,6 +103,21 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh\n $(GITGUI_BUILT_INS): git-gui\n \t$(QUIET_BUILT_IN)rm -f $@ && ln git-gui $@\n \n+XGETTEXT ?= xgettext\n+msgsdir ?= $(libdir)/msgs\n+msgsdir_SQ = $(subst ','\\'',$(msgsdir))\n+PO_TEMPLATE = po/git-gui.pot\n+ALL_POFILES = $(wildcard po/*.po)\n+ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))\n+\n+$(PO_TEMPLATE): $(SCRIPT_SH) $(ALL_LIBFILES)\n+\t$(XGETTEXT) -kmc -LTcl -o $@ $(SCRIPT_SH) $(ALL_LIBFILES)\n+update-po:: $(PO_TEMPLATE)\n+\t$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) )\n+$(ALL_MSGFILES): %.msg : %.po\n+\t@echo Generating catalog $@\n+\tmsgfmt --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)\n+\n lib/tclIndex: $(ALL_LIBFILES)\n \t$(QUIET_INDEX)if echo \\\n \t $(foreach p,$(PRELOAD_FILES),source $p\\;) \\\n@@ -136,7 +151,7 @@ GIT-GUI-VARS: .FORCE-GIT-GUI-VARS\n \t\techo 1>$@ \"$$VARS\"; \\\n \tfi\n \n-all:: $(ALL_PROGRAMS) lib/tclIndex\n+all:: $(ALL_PROGRAMS) lib/tclIndex $(ALL_MSGFILES)\n \n install: all\n \t$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(gitexecdir_SQ)' $(INSTALL_D1)\n@@ -145,6 +160,8 @@ install: all\n \t$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(libdir_SQ)' $(INSTALL_D1)\n \t$(QUIET)$(INSTALL_R0)lib/tclIndex $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)'\n \t$(QUIET)$(foreach p,$(ALL_LIBFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(libdir_SQ)' &&) true\n+\t$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(INSTALL_D1)\n+\t$(QUIET)$(foreach p,$(ALL_MSGFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true\n \n dist-version:\n \t@mkdir -p $(TARDIR)\n-- \n1.5.2\n"},{"id":"48035","messageId":"200707211437.43524.stimming@tuhh.de","threadId":"9108","inReplyTo":"200707211436.44672.stimming@tuhh.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T12:37:43Z","receivedAt":"2007-07-21T12:37:43Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"From 37241c4142c6bfe18e94a1891dbf1a9d1ee2953d Mon Sep 17 00:00:00 2001\nFrom: Christian Stimming \nDate: Sat, 21 Jul 2007 14:18:14 +0200\nSubject: [PATCH] Initial German translation for testing of i18n.\n\n\nSigned-off-by: Christian Stimming \n---\nAnd a new German translation, so far 100% but many more strings are to come.\n\n po/de.po | 265 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 265 insertions(+), 0 deletions(-)\n create mode 100644 po/de.po\n\ndiff --git a/po/de.po b/po/de.po\nnew file mode 100644\nindex 0000000..0592836\n--- /dev/null\n+++ b/po/de.po\n@@ -0,0 +1,265 @@\n+# Translation of git-gui to German.\n+# Copyright (C) 2007 Linux Torvalds\n+# This file is distributed under the same license as the git package.\n+# Christian Stimming , 2007\n+#\n+msgid \"\"\n+msgstr \"\"\n+\"Project-Id-Version: git-gui\\n\"\n+\"Report-Msgid-Bugs-To: \\n\"\n+\"POT-Creation-Date: 2007-07-19 15:10+0200\\n\"\n+\"PO-Revision-Date: 2007-07-19 15:11+0200\\n\"\n+\"Last-Translator: Christian Stimming \\n\"\n+\"Language-Team: German\\n\"\n+\"MIME-Version: 1.0\\n\"\n+\"Content-Type: text/plain; charset=UTF-8\\n\"\n+\"Content-Transfer-Encoding: 8bit\\n\"\n+\n+#: git-gui.sh:1621\n+msgid \"Repository\"\n+msgstr \"Projektarchiv\"\n+\n+#: git-gui.sh:1622\n+msgid \"Edit\"\n+msgstr \"Bearbeiten\"\n+\n+#: git-gui.sh:1624\n+msgid \"Branch\"\n+msgstr \"Zweig\"\n+\n+#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134\n+msgid \"Commit\"\n+msgstr \"Übertragen\"\n+\n+#: git-gui.sh:1630\n+msgid \"Merge\"\n+msgstr \"Zusammenführen\"\n+\n+#: git-gui.sh:1631\n+msgid \"Fetch\"\n+msgstr \"Holen\"\n+\n+#: git-gui.sh:1632 git-gui.sh:2140\n+msgid \"Push\"\n+msgstr \"Schieben\"\n+\n+#: git-gui.sh:1641\n+msgid \"Browse Current Branch\"\n+msgstr \"Aktuellen Zweig durchblättern\"\n+\n+#: git-gui.sh:1647\n+msgid \"Visualize Current Branch\"\n+msgstr \"Aktuellen Zweig darstellen\"\n+\n+#: git-gui.sh:1651\n+msgid \"Visualize All Branches\"\n+msgstr \"Alle Zweige darstellen\"\n+\n+#: git-gui.sh:1656\n+msgid \"Database Statistics\"\n+msgstr \"Datenbankstatistik\"\n+\n+#: git-gui.sh:1659\n+msgid \"Compress Database\"\n+msgstr \"Datenbank komprimieren\"\n+\n+#: git-gui.sh:1662\n+msgid \"Verify Database\"\n+msgstr \"Datenbank prüfen\"\n+\n+#: git-gui.sh:1669 git-gui.sh:1673 git-gui.sh:1677\n+msgid \"Create Desktop Icon\"\n+msgstr \"Desktop-Icon erstellen\"\n+\n+#: git-gui.sh:1682\n+msgid \"Quit\"\n+msgstr \"Beenden\"\n+\n+#: git-gui.sh:1689\n+msgid \"Undo\"\n+msgstr \"Rückgängig\"\n+\n+#: git-gui.sh:1692\n+msgid \"Redo\"\n+msgstr \"Wiederholen\"\n+\n+#: git-gui.sh:1696 git-gui.sh:2204\n+msgid \"Cut\"\n+msgstr \"Ausschneiden\"\n+\n+#: git-gui.sh:1699 git-gui.sh:2207 git-gui.sh:2278 git-gui.sh:2350\n+msgid \"Copy\"\n+msgstr \"Kopieren\"\n+\n+#: git-gui.sh:1702 git-gui.sh:2210\n+msgid \"Paste\"\n+msgstr \"Einfügen\"\n+\n+#: git-gui.sh:1705 git-gui.sh:2213\n+msgid \"Delete\"\n+msgstr \"Löschen\"\n+\n+#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354\n+msgid \"Select All\"\n+msgstr \"Alle auswählen\"\n+\n+#: git-gui.sh:1718\n+msgid \"Create...\"\n+msgstr \"Erstellen...\"\n+\n+#: git-gui.sh:1724\n+msgid \"Checkout...\"\n+msgstr \"Auschecken...\"\n+\n+#: git-gui.sh:1730\n+msgid \"Rename...\"\n+msgstr \"Umbenennen...\"\n+\n+#: git-gui.sh:1735 git-gui.sh:1833\n+msgid \"Delete...\"\n+msgstr \"Löschen...\"\n+\n+#: git-gui.sh:1740\n+msgid \"Reset...\"\n+msgstr \"Zurücksetzen...\"\n+\n+#: git-gui.sh:1752 git-gui.sh:2151\n+msgid \"New Commit\"\n+msgstr \"Neu übertragen\"\n+\n+#: git-gui.sh:1760 git-gui.sh:2158\n+msgid \"Amend Last Commit\"\n+msgstr \"Letzte Übertragung ergänzen\"\n+\n+#: git-gui.sh:1769 git-gui.sh:2118\n+msgid \"Rescan\"\n+msgstr \"Neu laden\"\n+\n+#: git-gui.sh:1775\n+msgid \"Add To Commit\"\n+msgstr \"Zur Bereitstellung hinzufügen\"\n+\n+#: git-gui.sh:1780\n+msgid \"Add Existing To Commit\"\n+msgstr \"Existierendes zur Bereitstellung hinzufügen\"\n+\n+#: git-gui.sh:1786\n+msgid \"Unstage From Commit\"\n+msgstr \"Aus der Bereitstellung herausnehmen\"\n+\n+#: git-gui.sh:1791\n+msgid \"Revert Changes\"\n+msgstr \"Änderungen verwerfen\"\n+\n+#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n+msgid \"Sign Off\"\n+msgstr \"Freizeichnen\"\n+\n+#: git-gui.sh:1813\n+msgid \"Local Merge...\"\n+msgstr \"Lokales Zusammenführen...\"\n+\n+#: git-gui.sh:1817\n+msgid \"Abort Merge...\"\n+msgstr \"Zusammenführen abbrechen...\"\n+\n+#: git-gui.sh:1830\n+msgid \"Push...\"\n+msgstr \"Schieben...\"\n+\n+#: git-gui.sh:1840\n+msgid \"Apple\"\n+msgstr \"Apple\"\n+\n+#: git-gui.sh:1843 git-gui.sh:1888\n+#, tcl-format\n+msgid \"About %s\"\n+msgstr \"Über %s\"\n+\n+#: git-gui.sh:1845 git-gui.sh:1851 git-gui.sh:2396\n+msgid \"Options...\"\n+msgstr \"Optionen...\"\n+\n+#: git-gui.sh:1873\n+msgid \"Tools\"\n+msgstr \"Werkzeuge\"\n+\n+#: git-gui.sh:1875\n+msgid \"Migrate\"\n+msgstr \"Migrieren\"\n+\n+#: git-gui.sh:1884\n+msgid \"Help\"\n+msgstr \"Hilfe\"\n+\n+#: git-gui.sh:1925\n+msgid \"Online Documentation\"\n+msgstr \"Online-Dokumentation\"\n+\n+#: git-gui.sh:2036\n+msgid \"Current Branch:\"\n+msgstr \"Aktueller Zweig:\"\n+\n+#: git-gui.sh:2057\n+msgid \"Staged Changes (Will Be Committed)\"\n+msgstr \"Bereitgestellte Änderungen (werden übertragen)\"\n+\n+#: git-gui.sh:2077\n+msgid \"Unstaged Changes (Will Not Be Committed)\"\n+msgstr \"Nicht bereitgestellte Änderungen (werden nicht übertragen)\"\n+\n+#: git-gui.sh:2124\n+msgid \"Add Existing\"\n+msgstr \"Existierendes hinzufügen\"\n+\n+#: git-gui.sh:2170\n+msgid \"Initial Commit Message:\"\n+msgstr \"Erstmalige Übertragungsmeldung\"\n+\n+#: git-gui.sh:2171\n+msgid \"Amended Commit Message:\"\n+msgstr \"Zur Übertragungsmeldung hinzufügen:\"\n+\n+#: git-gui.sh:2172\n+msgid \"Amended Initial Commit Message:\"\n+msgstr \"Zur erstmaligen Übertragungsmeldung hinzufügen:\"\n+\n+#: git-gui.sh:2173\n+msgid \"Amended Merge Commit Message:\"\n+msgstr \"Zur Zusammenführungs-Übertragungsmeldung hinzufügen:\"\n+\n+#: git-gui.sh:2174\n+msgid \"Merge Commit Message:\"\n+msgstr \"Übertragungsmeldung Zusammenführung:\"\n+\n+#: git-gui.sh:2175\n+msgid \"Commit Message:\"\n+msgstr \"Übertragungsmeldung:\"\n+\n+#: git-gui.sh:2220 git-gui.sh:2358\n+msgid \"Copy All\"\n+msgstr \"Alle kopieren\"\n+\n+#: git-gui.sh:2346\n+msgid \"Refresh\"\n+msgstr \"Aktualisieren\"\n+\n+#: git-gui.sh:2367\n+msgid \"Apply/Reverse Hunk\"\n+msgstr \"Änderung anwenden/umkehren\"\n+\n+#: git-gui.sh:2373\n+msgid \"Decrease Font Size\"\n+msgstr \"Schriftgröße verkleinern\"\n+\n+#: git-gui.sh:2377\n+msgid \"Increase Font Size\"\n+msgstr \"Schriftgröße vergrößern\"\n+\n+#: git-gui.sh:2382\n+msgid \"Show Less Context\"\n+msgstr \"Weniger Kontext anzeigen\"\n+\n+#: git-gui.sh:2389\n+msgid \"Show More Context\"\n+msgstr \"Mehr Kontext anzeigen\"\n-- \n1.5.2\n"},{"id":"48036","messageId":"200707211441.25119.stimming@tuhh.de","threadId":"9108","inReplyTo":"200707211437.43524.stimming@tuhh.de","subject":"Re: [PATCH 5/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T12:41:24Z","receivedAt":"2007-07-21T12:41:24Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"From f074190d3bf1c08cd833afaa7ba42731b1e7f572 Mon Sep 17 00:00:00 2001\nFrom: Christian Stimming \nDate: Sat, 21 Jul 2007 14:39:24 +0200\nSubject: [PATCH] Add glossary to ensure consistent translations.\n\n\nSigned-off-by: Christian Stimming \n---\nAnd last but not least an initial list of the most important terms throughout git \nand git-gui; out of convenience I've already included my decisions on German \ntranslation wordings but in the future those translations will probably be collected \nelsewhere.\n\n po/glossary.csv | 24 ++++++++++++++++++++++++\n 1 files changed, 24 insertions(+), 0 deletions(-)\n create mode 100644 po/glossary.csv\n\ndiff --git a/po/glossary.csv b/po/glossary.csv\nnew file mode 100644\nindex 0000000..e6ffe46\n--- /dev/null\n+++ b/po/glossary.csv\n@@ -0,0 +1,24 @@\n+\"English Term\"\t\"de translation\"\n+\"amend\"\t\"ergänzen\"\n+\"annotate\"\t\"annotieren\"\n+\"branch\"\t\"Zweig, verzweigen\"\n+\"checkout\"\t\"Auschecken\"\n+\"commit\"\t\"übertragen (senden?, übergeben?)\"\n+\"diff\"\t\"vergleichen\"\n+\"fetch\"\t\"holen\"\n+\"merge\"\t\"zusammenführen\"\n+\"message\"\t\"Meldung\"\n+\"pull\"\t\"ziehen (übernehmen?)\"\n+\"push\"\t\"schieben (hochladen? verschicken?)\"\n+\"redo\"\t\"Wiederholen\"\n+\"repository\"\t\"Projektarchiv\"\n+\"reset\"\t\"Zurücksetzen\"\n+\"revert\"\t\"zurückkehren\"\n+\"revision\"\t\"Revision\"\n+\"sign off\"\t\"freizeichnen\"\n+\"staging area\"\t\"Bereitstellung\"\n+\"status\"\t\"Status\"\n+\"tag\"\t\"Markierung, markieren\"\n+\"undo\"\t\"Rückgängig\"\n+\"update\"\t\"aktualisieren\"\n+\"working copy\"\t\"Arbeitskopie\"\n-- \n1.5.2\n"},{"id":"48039","messageId":"85ps2l98eq.fsf@lola.goethe.zz","threadId":"9108","inReplyTo":"200707211437.43524.stimming@tuhh.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-21T13:46:21Z","receivedAt":"2007-07-21T13:46:21Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Christian Stimming writes:\n\n> And a new German translation, so far 100% but many more strings are to come.\n>\n> po/de.po | 265 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n> 1 files changed, 265 insertions(+), 0 deletions(-)\n> create mode 100644 po/de.po\n\nI have somewhat different proposals which sound less awkward, I\nthink. Of course, it is always a matter of taste whether a technical\nterm should really be translated always, but assuming that, I'll make\nsome German proposals. Some may be tongue in cheek.\n\n> +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134\n> +msgid \"Commit\"\n> +msgstr \"Übertragen\"\n\nEinpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein\npassendes Substantiv zu finden. \"Sendung\"?\n\n> +#: git-gui.sh:1631\n> +msgid \"Fetch\"\n> +msgstr \"Holen\"\n\nImportieren (hauptsächlich, weil es zu Exportieren paßt und Schieben\nhäßlich ist)\n\n> +#: git-gui.sh:1632 git-gui.sh:2140\n> +msgid \"Push\"\n> +msgstr \"Schieben\"\n\nExportieren\n\n> +#: git-gui.sh:1641\n> +msgid \"Browse Current Branch\"\n> +msgstr \"Aktuellen Zweig durchblättern\"\n\nIm aktuellen Zweig stöbern.\n\n> +#: git-gui.sh:1659\n> +msgid \"Compress Database\"\n> +msgstr \"Datenbank komprimieren\"\n\nGanz Deutsch: verdichten.\n\n> +\n> +#: git-gui.sh:1662\n> +msgid \"Verify Database\"\n> +msgstr \"Datenbank prüfen\"\n\nüberprüfen (prüfen wäre eher zu \"checking\")\n\n> +#: git-gui.sh:1669 git-gui.sh:1673 git-gui.sh:1677\n> +msgid \"Create Desktop Icon\"\n> +msgstr \"Desktop-Icon erstellen\"\n\nDa gibt es sicher einen neudeutschen Ausdruck, aber als\nNichtwindowsnutzer mit Amilokale...\n\n> +#: git-gui.sh:1689\n> +msgid \"Undo\"\n> +msgstr \"Rückgängig\"\n\nAch nein.\n\n> +#: git-gui.sh:1692\n> +msgid \"Redo\"\n> +msgstr \"Wiederholen\"\n\nJetzt doch.\n\n> +#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354\n> +msgid \"Select All\"\n> +msgstr \"Alle auswählen\"\n\nAlles auswählen zöge ich vor.\n\n> +#: git-gui.sh:1724\n> +msgid \"Checkout...\"\n> +msgstr \"Auschecken...\"\n\nAusspielung.\n\n> +#: git-gui.sh:1752 git-gui.sh:2151\n> +msgid \"New Commit\"\n> +msgstr \"Neu übertragen\"\n\nNeue Sendung\n\n> +#: git-gui.sh:1760 git-gui.sh:2158\n> +msgid \"Amend Last Commit\"\n> +msgstr \"Letzte Übertragung ergänzen\"\n\nLetzte Sendung korrigieren.\n\n> +#: git-gui.sh:1775\n> +msgid \"Add To Commit\"\n> +msgstr \"Zur Bereitstellung hinzufügen\"\n\nDer Sendung hinzufügen.\n\n> +#: git-gui.sh:1780\n> +msgid \"Add Existing To Commit\"\n> +msgstr \"Existierendes zur Bereitstellung hinzufügen\"\n\nDer Sendung hinzufügen.\n\n> +#: git-gui.sh:1786\n> +msgid \"Unstage From Commit\"\n> +msgstr \"Aus der Bereitstellung herausnehmen\"\n\nAus der Sendung entfernen.\n\n> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n> +msgid \"Sign Off\"\n> +msgstr \"Freizeichnen\"\n\nGegenzeichnen?\n\n> +#: git-gui.sh:2057\n> +msgid \"Staged Changes (Will Be Committed)\"\n> +msgstr \"Bereitgestellte Änderungen (werden übertragen)\"\n\nEinzupflegende Änderungen\n\n> +#: git-gui.sh:2077\n> +msgid \"Unstaged Changes (Will Not Be Committed)\"\n> +msgstr \"Nicht bereitgestellte Änderungen (werden nicht übertragen)\"\n\nNicht einzupflegende Änderungen\n\nSo, jetzt geht mir die Luft aus.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48040","messageId":"Pine.LNX.4.64.0707211427190.14781@racer.site","threadId":"9108","inReplyTo":"200707211433.29318.stimming@tuhh.de","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-21T14:22:16Z","receivedAt":"2007-07-21T14:22:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 21 Jul 2007, Christian Stimming wrote:\n\n> This patch starts over from before the first i18n patch has been applied \n> and takes into account all discussion with Shawn. Currently I don't \n> quite know how to apply these patches to the \"mob\" branch because one \n> would have to first revert those patches from me that have been applied \n> there... Thanks.\n\nUsually you solve this by forcing a non-fastforwarding push. IOW you \nreally revert part of the history. You would not even have had to call \n\"git revert\" or \"git reset\", since you started from a defined commit, \nd36cd968378cd3e509434b1b9f43f1417fdba57e.\n\n_However_: Junio already pushed into the 'mob' branch, and if you would \nhave forced a non-fastforwarding push, this commit would have been lost. \nAt least from the repo's POV.\n\nSo the only real option that makes sense is for you to register as a user \nat repo.or.cz, send me your user name, and for me to add you as user so \nthat you can push into your own branch easily.\n\nFWIW, this is what I did with your patch series:\n\n- I looked at the first diff to find out which version of git-gui.sh it \n was based on:\n\n\tdiff --git a/git-gui.sh b/git-gui.sh\n\tindex c5ff7c8..0c5ca46 100755\n\t--- a/git-gui.sh\n\t+++ b/git-gui.sh\n\n Ah, okay, git-gui.sh was at c5ff7c8. What commit was that? Ask \"git \n log --raw\":\n\n\t...\n\tcommit d36cd968378cd3e509434b1b9f43f1417fdba57e\n\tAuthor: Shawn O. Pearce \n\tDate: Thu Jul 19 00:43:16 2007 -0400\n\n\t git-gui: Avoid unnecessary global statements when possible\n\n\t [commit message]\n\n\t:100755 100755 0aabfba... c5ff7c8... M git-gui.sh\n\n Good. So it is based on d36cd968. (If my decorate patch would be in \n 'master', I could have told you an easy name like \"shawn/master~3\" or \n some such).\n\n- I started a new branch:\n\n git checkout -b christian-new d36cd968\n\n- Then I saved all your mails into an own mbox with my mail program. I \n had to edit that mbox a little, since you sent the complete headers in \n the body, not in the mail header. So I just stripped all the \n mail headers and only left the ones from the mail bodies.\n\n- After that I applied the patches with\n\n git am -i \n\n I like the interactive mode, especially since Pine likes to add a dummy \n mail at the beginning of the mbox file, which I do not want to commit, \n of course ;-)\n\n- There were no conflicts at all, and just to see that nothing untoward \n happened, I compared the diffstats with \"git log --stat shawn/master..\"\n\n Come to think of it, it's even easier to check the object name of the \n new git-gui.sh: \"git ls-files --stage\" says\n\n\t...\n\t100755 95dac55[...] 0 git-gui.sh\n\n Worked. (I could also have said \"git log --raw\" to see that.)\n\n- Just a quick \"make && ./git-gui\" test. Ooops:\n\n\t$ LC_ALL=C make\n\tGenerating catalog po/de.msg\n\tmsgfmt --statistics --tcl po/de.po -l de -d po/\n\tpo/de.po:32:9: invalid multibyte sequence\n\tpo/de.po:36:18: invalid multibyte sequence\n\tpo/de.po:48:32: invalid multibyte sequence\n\t...\n\n Looking into line 32 I see an ISO-8859-1 'ü'. But in the header it says \n that it's UTF-8. Just a quick try: change that to ISO-8859-1, and \n 'make' says:\n\n\t$ LC_ALL=C make\n\tGenerating catalog po/de.msg\n\tmsgfmt --statistics --tcl po/de.po -l de -d po/\n\t62 translated messages.\n\n Much better.\n\n Okay, let's fix that up. First stash the changes:\n\n\t$ git stash encoding fix\n\n Then find out which commit added po/de.msg:\n\n\t$ git log -1 po/de.po\n\t...\n\t Initial German translation [...]\n\n Now on to editing the patch series:\n\n\t$ git rebase -i HEAD~5\n\n Mark \"Initial German translation [...]\" with the command \"edit\" instead \n of \"pick\". Save, and wait for half a second.\n\n\t...\n\tYou can amend the commit now, with\n\n\t git commit --amend\n\n Apply the stashed changes, and make sure that it's what I want:\n\n\t$ git stash apply\n\t...\n\t$ git diff\n\t...\n\t-\"Content-Type: text/plain; charset=UTF-8\\n\"\n\t+\"Content-Type: text/plain; charset=ISO-8859-1\\n\"\n\t...\n\n Yes! Amend the commit, and for good measure, sign off on it (after \n reading it, of course):\n\n\t$ git commit --amend -s po/de.po\n\n Mention that the encoding was changed by me, so if it is wrong, it is \n all my fault, not yours.\n\n Now finish \"rebasing\"...\n\n\t$ git rebase --continue\n\n Make sure that it works now:\n\n\t$ make libdir=$(pwd)/lib && ./git-gui\n\n Yep. Everything's fine.\n\n (Usually I go through this procedure in less than 3 minutes, but today I \n took more than double that, since I wrote this email explaining my \n actions...)\n\n- Push to repo.or.cz (which is my 'origin' remote):\n\n\t$ git push origin HEAD:refs/heads/christian-new\n\n- Now for the real fun: rebase it on top of Shawn's new master:\n\n\t# I have installed a remote 'shawn' pointing to git-gui.git\n\t$ git fetch shawn\n\t$ git rebase shawn/master\n\t...\n\n Worked. Just like that. Brilliant.\n\n- Let's just cherry-pick Junio's change, which is the latest commit in \n origin/mob:\n\n\t$ git cherry-pick origin/mob\n\tAuto-merged Makefile\n\tCONFLICT (content): Merge conflict in Makefile\n\tAutomatic cherry-pick failed. After resolving the conflicts,\n\tmark the corrected paths with 'git-add '\n\tand commit the result.\n\tWhen commiting, use the option '-c 2d29ab2' to retain authorship \n\tand message.\n\n Conflict in Makefile. Okay, no problem, edit it. Ah, of course, Shawn \n asked for automatic inferring of the available languages, while Junio \n added \"ja\". Just take the current version (the version between \"<<<<\" \n and \"====\").\n\n\t$ git add -u\n\t$ git commit -c 2d29ab2\n\n- Make the current revision my new 'master'. That branch already exists, \n and I am on 'christian-new', though. No problem:\n\n\t$ git branch -M christian-new master\n\n (But if you do that with \"-M\", which means _force_ rename, make sure \n twice that this is really what you want.)\n\n- Push it.\n\n\t$ git push origin +master\n\t...\n\trefs/heads/master: da7b699[...] -> cc2b761b[...]\n\n The \"+\" is necessary, since I rebased it...\n\n If there were more pushers than just me, I'd verify that da7b699 is \n indeed the old state of my master:\n\n\t$ git reflog\n\t...\n\td36cd96... HEAD@{20}: checkout: moving from master to christian-new\n\tda7b699... HEAD@{21}: commit [...]\n\n Yep.\n\nGood. Happy.\n\nCiao,\nDscho\n\n\n"},{"id":"48043","messageId":"46A233DE.6010304@fs.ei.tum.de","threadId":"9108","inReplyTo":"85ps2l98eq.fsf@lola.goethe.zz","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Simon 'corecode' Schubert","fromEmail":"corecode@fs.ei.tum.de","sentAt":"2007-07-21T16:27:10Z","receivedAt":"2007-07-21T16:27:10Z","isPatch":true,"sender":{"key":"corecode@fs.ei.tum.de","avatar":"https://gravatar.com/avatar/eff9dbf0cdac0d1e6a6cd7ed0e50763edcb376b493b5253a35ff167918ad79e1?d=mp&s=160"},"body":"David Kastrup wrote:\n>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n>> +msgid \"Sign Off\"\n>> +msgstr \"Freizeichnen\"\n> \n> Gegenzeichnen?\n\nAbzeichnen!\n"},{"id":"48048","messageId":"85ps2lslgk.fsf@lola.goethe.zz","threadId":"9108","inReplyTo":"46A233DE.6010304@fs.ei.tum.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-21T17:41:47Z","receivedAt":"2007-07-21T17:41:47Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Simon 'corecode' Schubert writes:\n\n> David Kastrup wrote:\n>>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n>>> +msgid \"Sign Off\"\n>>> +msgstr \"Freizeichnen\"\n>>\n>> Gegenzeichnen?\n>\n> Abzeichnen!\n\nAbsegnen. Ich denke mal, in der Form mit \"Ab\" ist das dermaßen\ngebräuchlich, daß man damit keine religiösen Befindlichkeiten\nverletzt.\n\nAnsonsten: Abnicken oder Gutheißen.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48051","messageId":"200707212050.48568.stimming@tuhh.de","threadId":"9108","inReplyTo":"85ps2l98eq.fsf@lola.goethe.zz","subject":"Re: Translation process (was: [PATCH 3/5] Internationalization of git-gui)","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T18:50:48Z","receivedAt":"2007-07-21T18:50:48Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:\n> Christian Stimming writes:\n> > And a new German translation, so far 100% but many more strings are to\n> > come.\n>\n> I have somewhat different proposals which sound less awkward, I\n> think. Of course, it is always a matter of taste whether a technical\n> term should really be translated always, but assuming that, I'll make\n> some German proposals. Some may be tongue in cheek.\n\nThanks for the suggestions. However, I don't think it is of much worth to \ndiscuss individual message translations *right now*; instead, here's what I \nwould propose instead:\n\nThe most difficult issue in a program translation is to find good translation \nwordings for those key words which are used each and every time throughout \nthe program. Once you've decided on a particular translation for each of \nthese words, the rest is just grunt work. So the important part is to \ntranslate these key words. Incidentally, I've added the file po/glossary.cvs \nfor exactly this purpose. In there you find my current collection of key \nwords that occur throughout git-gui (and git, for that matter), including a \nset of proposed translations to German language. This should be the place \nwhere the keyword translations should be discussed first. The discussion of \nthe actual translations should be deferred until after the glossary \ntranslations have been discussed and agreed upon.\n\n(I'm unsure whether the translations should be kept in the same glossary file; \nin the glossary for the gnucash project [1] we've actually added an extra \ndirectory and encourage translators to add an extra po file for their \nglossary translations. However, the glossary of gnucash has more than 150 \nterms and many of them require to be defined clearly as well, as translators \nwould otherwise be unable to translate them concisely. In git-gui, the \nglossary is 25 terms so far and I think the git documentation already \ncontains enough definitions of all of them. Nevertheless, maybe it would make \na better structure if the translations of the glossary are kept in a separate \npo file for each language. Hm.)\n\nIn short: Please discuss the glossary first, and not the actual de.po message \nfile. Once the glossary has been decided upon, the de.po will be adapted, and \n*after that* a discussion of de.po makes sense. But not before that.\n\nRegards,\n\nChristian\n\n[1] \nhttp://svn.gnucash.org/trac/browser/gnucash/trunk/po/glossary/gnc-glossary.txt\n"},{"id":"48053","messageId":"200707212127.51840.stimming@tuhh.de","threadId":"9108","inReplyTo":"85ps2l98eq.fsf@lola.goethe.zz","subject":"Re: German translations (was: [PATCH 3/5] Internationalization of git-gui)","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T19:27:51Z","receivedAt":"2007-07-21T19:27:51Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:\n> Christian Stimming writes:\n> > And a new German translation, so far 100% but many more strings are to\n> > come.\n>\n> I have somewhat different proposals which sound less awkward, I\n> think. Of course, it is always a matter of taste whether a technical\n> term should really be translated always, but assuming that, I'll make\n> some German proposals. Some may be tongue in cheek.\n\nThanks for additional word proposals. I'll discuss these and the two followups \nin German below.\n\n> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134\n> > +msgid \"Commit\"\n> > +msgstr \"Übertragen\"\n>\n> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein\n> passendes Substantiv zu finden. \"Sendung\"?\n\nRichtig - eine Kombination Substantiv/Verb wird benötigt. Ich habe im \nGlossar \"übertragen (senden?, übergeben?)\". Ersteres wird bei TortoiseSVN \nbenutzt. Im Prinzip gehen die anderen auch; bei \"Sendung\"/\"senden\" befürchte \nich aber zu viele Mehrdeutigkeiten, wenn man z.B. davon redet. den commit \nüber TCP wohin senden will. Die Sendung wohin senden? Andererseits hat man \nbei Übertragung das gleiche Problem.\n\n> > +#: git-gui.sh:1631\n> > +msgid \"Fetch\"\n> > +msgstr \"Holen\"\n>\n> Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben\n> häßlich ist)\n\nImportieren ist bereits für \"git-{cvs,svn}import\" reserviert, kann also hier \nnicht verwendet werden. Deswegen wird was anderes benötigt. Für fetch und \npull gleichermaßen würden holen/ziehen/übernehmen gehen und man muss sich \nhalt auf eine Zuordnung festlegen.\n\n> > +#: git-gui.sh:1632 git-gui.sh:2140\n> > +msgid \"Push\"\n> > +msgstr \"Schieben\"\n>\n> Exportieren\n\nDito - bereits reserviert für git-cvsexport u.ä., also hier nicht benutzbar. \nDeswegen momentan dieses, ich bin aber auch nicht glücklich damit. Siehe \nGlossar: \"schieben (hochladen? verschicken?)\"\n\n> > +#: git-gui.sh:1641\n> > +msgid \"Browse Current Branch\"\n> > +msgstr \"Aktuellen Zweig durchblättern\"\n>\n> Im aktuellen Zweig stöbern.\n\nstöbern für \"to browse\"? Das ist aber definitiv nicht das, was normalerweise \nals Übersetzung von \"to browse\" gewählt wird. Da ist man eben bei blättern. \nAußerdem ist \"stöbern\" hart an der Grenze zur Flapsigkeit, die man (im \nGegensatz zum engl. Original) bei deutscher Software unbedingt vermeiden \nmuss.\n\n> > +#: git-gui.sh:1659\n> > +msgid \"Compress Database\"\n> > +msgstr \"Datenbank komprimieren\"\n>\n> Ganz Deutsch: verdichten.\n\nAlle E-Mail-Programme reden aber bereits von komprimieren (was in den Motoren \nschon immer ein deutscher Begriff war), so dass ich hier auch dabei bleiben \nwürde.\n\n> > +#: git-gui.sh:1662\n> > +msgid \"Verify Database\"\n> > +msgstr \"Datenbank prüfen\"\n>\n> überprüfen (prüfen wäre eher zu \"checking\")\n\n\"to verify\" -> überprüfen? Ok.\n\n> > +#: git-gui.sh:1709 git-gui.sh:2217 git-gui.sh:2354\n> > +msgid \"Select All\"\n> > +msgstr \"Alle auswählen\"\n>\n> Alles auswählen zöge ich vor.\n\nKommt auf den Kontext an - was soll denn ausgewählt werden? \"Alle Sendungen\" \noder \"Alles, was sichtbar ist\"...\n\n> > +#: git-gui.sh:1724\n> > +msgid \"Checkout...\"\n> > +msgstr \"Auschecken...\"\n>\n> Ausspielung.\n\nÄh... nein. Auschecken ist auch nicht so toll (auch hier übernommen von \nTortoiseSVN), aber was besseres hab ich noch nicht gefunden.\n\n> > +#: git-gui.sh:2057\n> > +msgid \"Staged Changes (Will Be Committed)\"\n> > +msgstr \"Bereitgestellte Änderungen (werden übertragen)\"\n>\n> Einzupflegende Änderungen\n\nNein, hier muss irgendwie die \"staging area\" mit auftauchen, denn so lautet \ndie Beschriftung der linken Listbox. Da ich die mit \"Bereitstellung\" gewählt \nhabe, muss das Wort hier wieder auftauchen. \n\n> > David Kastrup wrote:\n> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n> >>> +msgid \"Sign Off\"\n> >>> +msgstr \"Freizeichnen\"\n> >>\n> >> Gegenzeichnen?\n> >\n> > Abzeichnen!\n>\n> Absegnen.  Ich denke mal, in der Form mit \"Ab\" ist das dermaßen\n> gebräuchlich, daß man damit keine religiösen Befindlichkeiten\n> verletzt.\n>\n> Ansonsten: Abnicken oder Gutheißen.\n\nAbsegnen ist zu flapsig, Abnicken und Gutheißen erst recht. Gegenzeichnen \nlässt nicht erahnen, dass man seine eigenen commits ja auch \"sign off\" soll \n(wie z.B. in git.git/Documents/SubmittingPatches erklärt). Abzeichnen wäre \nokay, aber das ist Freizeichnen auch.\n\nGruß\n\nChristian\n"},{"id":"48054","messageId":"7vejj1v92b.fsf@assigned-by-dhcp.cox.net","threadId":"9108","inReplyTo":"Pine.LNX.4.64.0707211427190.14781@racer.site","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-21T19:41:16Z","receivedAt":"2007-07-21T19:41:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> ...\n> - Make the current revision my new 'master'. That branch already exists, \n> and I am on 'christian-new', though. No problem:\n>\n> \t$ git branch -M christian-new master\n>\n> (But if you do that with \"-M\", which means _force_ rename, make sure \n> twice that this is really what you want.)\n>\n> - Push it.\n>\n> \t$ git push origin +master\n> \t...\n> \trefs/heads/master: da7b699[...] -> cc2b761b[...]\n>\n> The \"+\" is necessary, since I rebased it...\n>\n> If there were more pushers than just me, I'd verify that da7b699 is \n> indeed the old state of my master:\n>\n> \t$ git reflog\n> \t...\n> \td36cd96... HEAD@{20}: checkout: moving from master to christian-new\n> \tda7b699... HEAD@{21}: commit [...]\n>\n> Yep.\n>\n> Good. Happy.\n\nTwo questions and a half.\n\n - The above means git-gui-i18n.git's master is rebased. Is\n that the intention? IOW, people are supposed to work on it\n with fetch+rebase, not fetch+merge (= pull)?\n\n - It seems that the tip of 'mob' now is out of sync wrt\n 'master'. What's the plan to update it with framework\n changes made in 'master' (e.g. addition of po/glossary.csv)?\n\nWhile I think keeping a reference for consistent translation\n(within one language's *.po file) is a useful practice,\nthe po/glossary.csv file on 'master' seems a way suboptimal\nsolution. Currently it is:\n\n $ file po/glossary.csv\n po/glossary.csv: ISO-8859 text\n\n $ head -n 1 po/glossary.csv\n \"English Term\" \"de translation\"\n\nwhich implies that other languages will be added at the end\nseparated with ?\n\nThere are two HUGE problems with that.\n\n * Supporting many languages means looooong lines in that file.\n Translators for languages later on the line would have hard\n time updating or looking at that file.\n\n * Mixed encodings. What if next language wants its strings in\n UTF-8? How would you have that and ISO-8859 on a same line?\n\nI would suggest having one glossary file per language.\n"},{"id":"48055","messageId":"200707212150.49351.stimming@tuhh.de","threadId":"9108","inReplyTo":"7vejj1v92b.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-21T19:50:48Z","receivedAt":"2007-07-21T19:50:48Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Samstag, 21. Juli 2007 21:41 schrieb Junio C Hamano:\n> While I think keeping a reference for consistent translation\n> (within one language's *.po file) is a useful practice,\n> the po/glossary.csv file on 'master' seems a way suboptimal\n> solution. Currently it is:\n>\n> $ file po/glossary.csv\n> po/glossary.csv: ISO-8859 text\n\nOops. I created it with utf8 locally. Must have turned into latin1 either in \nmy mailer or during Johannes' mbox tweaking.\n\n(Also, the de.po was created in utf8 here and must have been messed up during \ntransmission. Johannes, for future reference: All i18n files should probably \nbe submitted as utf8, and if they have a different encoding, the submitter \nbetter gave a clear sign this was intentional.)\n\n> $ head -n 1 po/glossary.csv\n> \"English Term\" \"de translation\"\n>\n> which implies that other languages will be added at the end\n> separated with ?\n>\n> There are two HUGE problems with that.\n>\n> * Supporting many languages means looooong lines in that file.\n> Translators for languages later on the line would have hard\n> time updating or looking at that file.\n>\n> * Mixed encodings. What if next language wants its strings in\n> UTF-8? How would you have that and ISO-8859 on a same line?\n>\n> I would suggest having one glossary file per language.\n\nAgreed. I propose to throw away the \"add glossary\" patch and I'll resubmit, \nthis time in a separate po/glossary/ directory, where each language will get \na po file for the glossary. \n\nAs I've written in another thread: In the glossary for the gnucash project [1] \nwe've actually added an extra \ndirectory and encourage translators to add an extra po file for their \nglossary translations. However, the glossary of gnucash has more than 150 \nterms and many of them require to be defined clearly as well, as translators \nwould otherwise be unable to translate them concisely. In git-gui, the \nglossary is 25 terms so far and I think the git documentation already \ncontains enough definitions of all of them. Nevertheless, maybe it would make \na better structure if the translations of the glossary are kept in a separate \npo file for each language. \n\nChristian\n\n[1] \nhttp://svn.gnucash.org/trac/browser/gnucash/trunk/po/glossary/gnc-glossary.txt\n"},{"id":"48056","messageId":"85tzrxr0m9.fsf@lola.goethe.zz","threadId":"9108","inReplyTo":"200707212127.51840.stimming@tuhh.de","subject":"Re: German translations","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-21T19:57:18Z","receivedAt":"2007-07-21T19:57:18Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Christian Stimming writes:\n\n> Am Samstag, 21. Juli 2007 15:46 schrieb David Kastrup:\n>> Christian Stimming writes:\n>> > And a new German translation, so far 100% but many more strings are to\n>> > come.\n>>\n>> I have somewhat different proposals which sound less awkward, I\n>> think. Of course, it is always a matter of taste whether a technical\n>> term should really be translated always, but assuming that, I'll make\n>> some German proposals. Some may be tongue in cheek.\n>\n> Thanks for additional word proposals. I'll discuss these and the two\n> followups in German below.\n>\n>> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134\n>> > +msgid \"Commit\"\n>> > +msgstr \"Übertragen\"\n>>\n>> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein\n>> passendes Substantiv zu finden. \"Sendung\"?\n>\n> Richtig - eine Kombination Substantiv/Verb wird benötigt. Ich habe im \n> Glossar \"übertragen (senden?, übergeben?)\". Ersteres wird bei TortoiseSVN \n> benutzt. Im Prinzip gehen die anderen auch; bei \"Sendung\"/\"senden\" befürchte \n> ich aber zu viele Mehrdeutigkeiten, wenn man z.B. davon redet. den commit \n> über TCP wohin senden will. Die Sendung wohin senden? Andererseits hat man \n> bei Übertragung das gleiche Problem.\n\nIch habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.\nSymmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.\n\n>> > +#: git-gui.sh:1631\n>> > +msgid \"Fetch\"\n>> > +msgstr \"Holen\"\n>>\n>> Importieren (hauptsächlich, weil es zu Exportieren paßt und Schieben\n>> häßlich ist)\n>\n> Importieren ist bereits für \"git-{cvs,svn}import\" reserviert, kann\n> also hier nicht verwendet werden.\n\nOk.\n\n> Deswegen wird was anderes benötigt. Für fetch und pull gleichermaßen\n> würden holen/ziehen/übernehmen gehen und man muss sich halt auf eine\n> Zuordnung festlegen.\n\nfetch = anfordern, pull = übernehmen?\n\n>> > +#: git-gui.sh:1632 git-gui.sh:2140\n>> > +msgid \"Push\"\n>> > +msgstr \"Schieben\"\n>>\n>> Exportieren\n>\n> Dito - bereits reserviert für git-cvsexport u.ä., also hier nicht\n> benutzbar. Deswegen momentan dieses, ich bin aber auch nicht\n> glücklich damit. Siehe Glossar: \"schieben (hochladen? verschicken?)\"\n\nAusliefern? Durchgeben?\n\n>> > +#: git-gui.sh:1641\n>> > +msgid \"Browse Current Branch\"\n>> > +msgstr \"Aktuellen Zweig durchblättern\"\n>>\n>> Im aktuellen Zweig stöbern.\n>\n> stöbern für \"to browse\"? Das ist aber definitiv nicht das, was\n> normalerweise als Übersetzung von \"to browse\" gewählt wird. Da ist\n> man eben bei blättern.\n\nAber das wäre \"leafing through\" und ist eben auf Bücher beschränkt.\n\n> Außerdem ist \"stöbern\" hart an der Grenze zur Flapsigkeit, die man\n> (im Gegensatz zum engl. Original) bei deutscher Software unbedingt\n> vermeiden muss.\n\nFinde ich nicht, aber bei Interfaces ist natürlich die\nMehrheitsmeinung ausschlaggebend. \"wühlen\" wäre flapsig. Etwas\nhochsprachlicher wäre noch \"durchforsten\", aber das trägt uns\nnatürlich den Zorn der Förster für den Begriffsmißbrauch zu.\n\"erkunden\" wäre auch noch möglich.\n\n>> > +#: git-gui.sh:2057\n>> > +msgid \"Staged Changes (Will Be Committed)\"\n>> > +msgstr \"Bereitgestellte Änderungen (werden übertragen)\"\n>>\n>> Einzupflegende Änderungen\n>\n> Nein, hier muss irgendwie die \"staging area\" mit auftauchen, denn so\n> lautet die Beschriftung der linken Listbox. Da ich die mit\n> \"Bereitstellung\" gewählt habe, muss das Wort hier wieder auftauchen.\n\nSehe ich zwar nicht so.\n\n>> > David Kastrup wrote:\n>> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n>> >>> +msgid \"Sign Off\"\n>> >>> +msgstr \"Freizeichnen\"\n>> >>\n>> >> Gegenzeichnen?\n>> >\n>> > Abzeichnen!\n>>\n>> Absegnen.  Ich denke mal, in der Form mit \"Ab\" ist das dermaßen\n>> gebräuchlich, daß man damit keine religiösen Befindlichkeiten\n>> verletzt.\n>>\n>> Ansonsten: Abnicken oder Gutheißen.\n>\n> Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht.\n\nAbnicken ja, aber Gutheißen ist nun wirklich ein hochsprachlicher\nBegriff.\n\n> Abzeichnen wäre okay, aber das ist Freizeichnen auch.\n\nFreizeichnen ist viel zu nischensprachlich. Mit Abzeichnen könnte ich\nleben, obwohl ich Gutheißen besser fände.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48057","messageId":"85odi5r01a.fsf@lola.goethe.zz","threadId":"9108","inReplyTo":"200707212127.51840.stimming@tuhh.de","subject":"Re: German translations","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-21T20:09:53Z","receivedAt":"2007-07-21T20:09:53Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nAfter a view of the glossary:\n\n\"amend\" \"ergänzen\"\n\nist nicht ganz korrekt. \"nachbessern\" wäre da erheblich besser.\n\"message\" würde ich als \"Nachricht\" statt \"Meldung\" übersetzen.\n\n\"revert\" \"zurückkehren\" würde ich eher als \"revidieren\" oder\n\"aufheben\" bezeichnen.\n\n\"revision\" ist wohl schlicht eine \"Version\" statt der \"Revision\", die\neinem das Finanzamt ins Haus bringt.\n\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48058","messageId":"Pine.LNX.4.64.0707212208110.14781@racer.site","threadId":"9108","inReplyTo":"7vejj1v92b.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-21T21:12:40Z","receivedAt":"2007-07-21T21:12:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 21 Jul 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > ...\n> > - Make the current revision my new 'master'. That branch already exists, \n> > and I am on 'christian-new', though. No problem:\n> >\n> > \t$ git branch -M christian-new master\n> >\n> > (But if you do that with \"-M\", which means _force_ rename, make sure \n> > twice that this is really what you want.)\n> >\n> > - Push it.\n> >\n> > \t$ git push origin +master\n> > \t...\n> > \trefs/heads/master: da7b699[...] -> cc2b761b[...]\n> >\n> > The \"+\" is necessary, since I rebased it...\n> >\n> > If there were more pushers than just me, I'd verify that da7b699 is \n> > indeed the old state of my master:\n> >\n> > \t$ git reflog\n> > \t...\n> > \td36cd96... HEAD@{20}: checkout: moving from master to christian-new\n> > \tda7b699... HEAD@{21}: commit [...]\n> >\n> > Yep.\n> >\n> > Good. Happy.\n> \n> Two questions and a half.\n> \n> - The above means git-gui-i18n.git's master is rebased. Is\n> that the intention? IOW, people are supposed to work on it\n> with fetch+rebase, not fetch+merge (= pull)?\n\nOkay, you have me there. Usually I am the one saying \"rebasing is bad\". \nSo I'll refrain from that practice. From now on, 'master' will _not_ be \nrebased. From time to time I will prepare 'for-shawn' branches, which are \n\"master rebased onto git-gui\".\n\nIn related news, I will push to 'mob' whenever I update 'master'. I will \nnever force a push to 'mob', and neither should anybody else have to. \n(Except in the case that you want to correct one of your pushes.)\n\n> - It seems that the tip of 'mob' now is out of sync wrt\n> 'master'. What's the plan to update it with framework\n> changes made in 'master' (e.g. addition of po/glossary.csv)?\n\nIMHO the best practice is to keep it up-to-date with 'master', as I \noutlined above.\n\n> [Half a question about po/glossary.csv]\n\nThis was answered by Christian, I guess.\n\nCiao,\nDscho\n"},{"id":"48059","messageId":"Pine.LNX.4.64.0707212219250.14781@racer.site","threadId":"9108","inReplyTo":"200707212150.49351.stimming@tuhh.de","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-21T21:20:35Z","receivedAt":"2007-07-21T21:20:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 21 Jul 2007, Christian Stimming wrote:\n\n> Am Samstag, 21. Juli 2007 21:41 schrieb Junio C Hamano:\n> > While I think keeping a reference for consistent translation\n> > (within one language's *.po file) is a useful practice,\n> > the po/glossary.csv file on 'master' seems a way suboptimal\n> > solution. Currently it is:\n> >\n> > $ file po/glossary.csv\n> > po/glossary.csv: ISO-8859 text\n> \n> Oops. I created it with utf8 locally. Must have turned into latin1 either in \n> my mailer or during Johannes' mbox tweaking.\n\nD'oh. I think it was my tweaking. But now, with 'mob' in place, there \nare less chances for me to fsck up.\n\nCiao,\nDscho\n"},{"id":"48061","messageId":"7vabtpv43d.fsf@assigned-by-dhcp.cox.net","threadId":"9108","inReplyTo":"200707212150.49351.stimming@tuhh.de","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-21T21:28:38Z","receivedAt":"2007-07-21T21:28:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Stimming writes:\n\n>> There are two HUGE problems with that.\n>>\n>> * Supporting many languages means looooong lines in that file.\n>> Translators for languages later on the line would have hard\n>> time updating or looking at that file.\n>>\n>> * Mixed encodings. What if next language wants its strings in\n>> UTF-8? How would you have that and ISO-8859 on a same line?\n>>\n>> I would suggest having one glossary file per language.\n>\n> Agreed. I propose to throw away the \"add glossary\" patch and I'll resubmit, \n> this time in a separate po/glossary/ directory, where each language will get \n> a po file for the glossary. \n>\n> As I've written in another thread: In the glossary for the gnucash project [1] \n> we've actually added an extra \n> directory and encourage translators to add an extra po file for their \n> glossary translations. However, the glossary of gnucash has more than 150 \n> terms and many of them require to be defined clearly as well, as translators \n> would otherwise be unable to translate them concisely. In git-gui, the \n> glossary is 25 terms so far and I think the git documentation already \n> contains enough definitions of all of them. Nevertheless, maybe it would make \n> a better structure if the translations of the glossary are kept in a separate \n> po file for each language. \n\nActually, I would even suggest that we should NOT have a\nseparate glossary file at all, if gettext suite allows what I\noutline below.\n\nHow about having it as a part of header comment in each of the\nxx.po file?\n\nThe division of labor I think would make sense for message l10n\nprocess goes like this:\n\n - The software developer (primarily Shawn): responsible for\n marking messages subject to i18n;\n\n - The i18n coordinator (could be Shawn but anybody else can\n volunteer; as things stand, I think Christian and Johannes\n are doing this): responsible for running \"make\n po/git-gui.pot; make update-po\" from time to time in order to\n keep po/*.po in sync with the vocabulary.\n\n initially, populate \"glossary\" part in po/git-gui.pot;\n\n as needed, add entries \"glossary\" part in po/git-gui.pot, and\n (if possible) add corresponding placeholders to po/*.po;\n\n - Translators (one for each language): responsible for updating\n po/xx.po file;\n\n initially, start by copying po/git-gui.pot to create\n po/xx.po;\n\n maintainance of \"glossary\" part of po/xx.po could also be\n made this person's responsibility instead of i18n\n coordinator's.\n\nThis way, the translators do not have to be so familiar with the\ngettext toolchain nor even have to have gettext installed.\n\n \n"},{"id":"48062","messageId":"Pine.LNX.4.64.0707212234500.14781@racer.site","threadId":"9108","inReplyTo":"7vabtpv43d.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-21T21:35:27Z","receivedAt":"2007-07-21T21:35:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 21 Jul 2007, Junio C Hamano wrote:\n\n> The division of labor I think would make sense for message l10n\n> process goes like this:\n> \n> - The software developer (primarily Shawn): responsible for\n> marking messages subject to i18n;\n> \n> - The i18n coordinator (could be Shawn but anybody else can\n> volunteer; as things stand, I think Christian and Johannes\n> are doing this): responsible for running \"make\n> po/git-gui.pot; make update-po\" from time to time in order to\n> keep po/*.po in sync with the vocabulary.\n> \n> initially, populate \"glossary\" part in po/git-gui.pot;\n> \n> as needed, add entries \"glossary\" part in po/git-gui.pot, and\n> (if possible) add corresponding placeholders to po/*.po;\n> \n> - Translators (one for each language): responsible for updating\n> po/xx.po file;\n> \n> initially, start by copying po/git-gui.pot to create\n> po/xx.po;\n> \n> maintainance of \"glossary\" part of po/xx.po could also be\n> made this person's responsibility instead of i18n\n> coordinator's.\n> \n> This way, the translators do not have to be so familiar with the\n> gettext toolchain nor even have to have gettext installed.\n\nMakes tons of sense to me.\n\nCiao,\nDscho\n"},{"id":"48065","messageId":"7vzm1ptmdm.fsf@assigned-by-dhcp.cox.net","threadId":"9108","inReplyTo":"Pine.LNX.4.64.0707212208110.14781@racer.site","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-21T22:36:37Z","receivedAt":"2007-07-21T22:36:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> Two questions and a half.\n>> \n>> - The above means git-gui-i18n.git's master is rebased. Is\n>> that the intention? IOW, people are supposed to work on it\n>> with fetch+rebase, not fetch+merge (= pull)?\n>\n> Okay, you have me there. Usually I am the one saying \"rebasing is bad\". \n> So I'll refrain from that practice. From now on, 'master' will _not_ be \n> rebased. From time to time I will prepare 'for-shawn' branches, which are \n> \"master rebased onto git-gui\".\n\nI did not mean to say \"rebase is bad\". Quite the contrary.\n\nRebase is bad for a repository meant for public consumption of\nthe under-development-snapshot, like git.git's 'master' and\n'next'. For a repository like git-gui-i18n whose sole point is\nto serve as a public gathering point of narrowly focused area of\ndevelopment (only translation of messages), I actually think\n\"everybody fetches and rebases\" workflow is perfectly fine, as\nlong as all participants understand what the expected workflows\nare. My comment was more about making it clear what the policy\nis to its intended audience.\n\nRebasing git-gui-i18n to keep its history clean would eventually\nallow you to merge it directly into git-gui. But if you are not\naiming for that (and you said your plan is to cherry pick the\nresult, not to merge, which is fine), then rebasing would no buy\nyou anything, so I think it would be a reasonable and manageable\nworkflow to:\n\n - people fork from 'mob', push back to 'mob';\n\n - you \n - build 'master' by cherry picking good bits from 'mob', and\n - do your own fixups and framework changes on 'master',\n - merge 'master' back to 'mob' to allow contributors to\n adjust their work on the updated 'master' by simply\n following 'mob',\n\n - and eventually clean-up 'master' to make it mergeable and/or\n applicable to git-gui itself.\n"},{"id":"48067","messageId":"Pine.LNX.4.64.0707212356270.14781@racer.site","threadId":"9108","inReplyTo":"7vzm1ptmdm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-21T23:01:01Z","receivedAt":"2007-07-21T23:01:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 21 Jul 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> Two questions and a half.\n> >> \n> >> - The above means git-gui-i18n.git's master is rebased. Is\n> >> that the intention? IOW, people are supposed to work on it\n> >> with fetch+rebase, not fetch+merge (= pull)?\n> >\n> > Okay, you have me there. Usually I am the one saying \"rebasing is bad\". \n> > So I'll refrain from that practice. From now on, 'master' will _not_ be \n> > rebased. From time to time I will prepare 'for-shawn' branches, which are \n> > \"master rebased onto git-gui\".\n> \n> I did not mean to say \"rebase is bad\". Quite the contrary.\n\nYeah, I was not really precise. Rebase is only bad for branches that want \nto be tracked.\n\nAs you can see from my work on rebase -i, I recently converted to an avid \nuser of rebase, from somebody who detested the feature a year ago.\n\n> [...] I think it would be a reasonable and manageable workflow to:\n> \n> - people fork from 'mob', push back to 'mob';\n> \n> - you \n> - build 'master' by cherry picking good bits from 'mob', and\n> - do your own fixups and framework changes on 'master',\n> - merge 'master' back to 'mob' to allow contributors to\n> adjust their work on the updated 'master' by simply\n> following 'mob',\n> \n> - and eventually clean-up 'master' to make it mergeable and/or\n> applicable to git-gui itself.\n\nI plan to pull and push from mob, from time to time \ncherry-picking/rebasing and cleaning up to a branch called 'for-shawn'. \nTo keep things a little synchronised, I plan to make grafts at stages \nwhere master^{tree} = for-shawn^{tree}, so that rebase is easier.\n\nCiao,\nDscho\n"},{"id":"48100","messageId":"20070722073806.GW32566@spearce.org","threadId":"9108","inReplyTo":"200707211433.29318.stimming@tuhh.de","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-22T07:38:06Z","receivedAt":"2007-07-22T07:38:06Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian Stimming wrote:\n> Subject: [PATCH] Initialize msgcat (gettext).\n...\n> diff --git a/git-gui.sh b/git-gui.sh\n> index c5ff7c8..0c5ca46 100755\n> --- a/git-gui.sh\n> +++ b/git-gui.sh\n> @@ -108,6 +108,12 @@ if {$idx ne {}} {\n> }\n> unset -nocomplain oguirel idx fd\n> \n> +## Internationalization (i18n) through msgcat and gettext. See\n> +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html\n> +package require msgcat\n> +::msgcat::mcload [file join $oguilib msgs]\n> +namespace import ::msgcat::mc\n> +\n\nThanks. We'll probably also want to modify the lib/class.tcl to\nimport ::msgcat::mc into the class namespace when it creates it.\nI use that class thing throught most of git-gui, especially for\nUI code. About 50% of git-gui has been converted to use class,\nthe other 50% is just global and is still in git-gui.sh. ;-)\n\n-- \nShawn.\n"},{"id":"48101","messageId":"20070722074525.GX32566@spearce.org","threadId":"9108","inReplyTo":"200707211434.56622.stimming@tuhh.de","subject":"Re: [PATCH 2/5] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-22T07:45:25Z","receivedAt":"2007-07-22T07:45:25Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian Stimming wrote:\n> Subject: [PATCH] Mark strings for translation.\n> \n> The procedure [mc ...] will translate the strings through msgcat.\n...\n> Here I marked much more strings than in the previous patch, and as discussed\n> the procedure [mc ...] is used for translation. Actually I think this pretty much \n> caught all occurrences of user-visible strings in *this* file; there will be many\n> more strings in all the other files, of course.\n\nAlmost. I noticed two that you did miss, and its because they are\ntotally weird. We may want to rewrite this block of code first...\n\n> @@ -1673,7 +1673,7 @@ if {[is_enabled transport]} {\n> menu .mbar.repository\n> \n> .mbar.repository add command \\\n> -\t-label {Browse Current Branch's Files} \\\n> +\t-label [mc \"Browse Current Branch's Files\"] \\\n> \t-command {browser::new $current_branch}\n> trace add variable current_branch write \".mbar.repository entryconf [.mbar.repository index last] -label \\\"Browse \\$current_branch's Files\\\" ;#\"\n> .mbar.repository add command \\\n> @@ -1682,69 +1682,69 @@ trace add variable current_branch write \".mbar.repository entryconf [.mbar.repos\n> .mbar.repository add separator\n> \n> .mbar.repository add command \\\n> -\t-label {Visualize Current Branch's History} \\\n> +\t-label [mc \"Visualize Current Branch's History\"] \\\n> \t-command {do_gitk $current_branch}\n> trace add variable current_branch write \".mbar.repository entryconf [.mbar.repository index last] -label \\\"Visualize \\$current_branch's History\\\" ;#\"\n> .mbar.repository add command \\\n\nSee those two trace lines? These things are setting up hooks to\nchange the menu item's label on the fly, so that the current branch\nname is shown in the item label. These will also need to use mc to\ntranslate the string. But they are in a double quoted string and will\nbe eval'd later by Tcl, so we actually need something like:\n\n- trace add variable current_branch write \".mbar.repository entryconf [.mbar.repository index last] -label \\\"Visualize \\$current_branch's History\\\" ;#\"\n+ trace add variable current_branch write \".mbar.repository entryconf [.mbar.repository index last] -label \\[mc \\\"Visualize \\$current_branch's History\\\"\\] ;#\"\n\nThese are (I think) the only two places in all of git-gui where\nthis wierdness happens. Converting this trace pair to a normal\nprocedure may make it easier to manage for translation.\n\n> -\t.mbar.apple add command -label \"About [appname]\" \\\n> +\t.mbar.apple add command -label [mc \"About %s\" appname] \\\n\nBug. This needs to be:\n\n+\t.mbar.apple add command -label [mc \"About %s\" [appname]] \\\n\nYou lost one level of [] there when you did the replacement.\nI only noticed this during a fast scan through while deleting text.\nI'll have to reread this patch more carefully later, before I apply\n(or merge) it, to make sure we don't have more such cases.\n\n-- \nShawn.\n"},{"id":"48102","messageId":"20070722074740.GY32566@spearce.org","threadId":"9108","inReplyTo":"200707211437.43524.stimming@tuhh.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-22T07:47:40Z","receivedAt":"2007-07-22T07:47:40Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian Stimming wrote:\n> Subject: [PATCH] Initial German translation for testing of i18n.\n...\n> diff --git a/po/de.po b/po/de.po\n> new file mode 100644\n> index 0000000..0592836\n> --- /dev/null\n> +++ b/po/de.po\n> @@ -0,0 +1,265 @@\n> +# Translation of git-gui to German.\n> +# Copyright (C) 2007 Linux Torvalds\n\nI didn't realize Linus wrote German. ;-)\n\nOr are you assigning the copyright to Linus, much as other chunks\nof Git are copyrighted by Linus?\n\n-- \nShawn.\n"},{"id":"48104","messageId":"7vodi4sw1e.fsf@assigned-by-dhcp.cox.net","threadId":"9108","inReplyTo":"20070722074740.GY32566@spearce.org","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-22T08:05:33Z","receivedAt":"2007-07-22T08:05:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Christian Stimming wrote:\n>> Subject: [PATCH] Initial German translation for testing of i18n.\n> ...\n>> diff --git a/po/de.po b/po/de.po\n>> new file mode 100644\n>> index 0000000..0592836\n>> --- /dev/null\n>> +++ b/po/de.po\n>> @@ -0,0 +1,265 @@\n>> +# Translation of git-gui to German.\n>> +# Copyright (C) 2007 Linux Torvalds\n>\n> I didn't realize Linus wrote German. ;-)\n>\n> Or are you assigning the copyright to Linus, much as other chunks\n> of Git are copyrighted by Linus?\n\nThe convention for xx.po, judging from the way template pot file\nis written out, is to name the package's copyright holder, not\ntranslation's, on that line. So Linus does not have to have\nanything to do with the German part, but I think the appropriate\nname to place there is yours.\n"},{"id":"48130","messageId":"200707221416.42908.stimming@tuhh.de","threadId":"9108","inReplyTo":"7vodi4sw1e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-22T12:16:42Z","receivedAt":"2007-07-22T12:16:42Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Sonntag, 22. Juli 2007 10:05 schrieb Junio C Hamano:\n> \"Shawn O. Pearce\" writes:\n> > Christian Stimming wrote:\n> >> Subject: [PATCH] Initial German translation for testing of i18n.\n> >> diff --git a/po/de.po b/po/de.po\n> >> new file mode 100644\n> >> index 0000000..0592836\n> >> --- /dev/null\n> >> +++ b/po/de.po\n> >> @@ -0,0 +1,265 @@\n> >> +# Translation of git-gui to German.\n> >> +# Copyright (C) 2007 Linux Torvalds\n> >\n> > I didn't realize Linus wrote German. ;-)\n> >\n> > Or are you assigning the copyright to Linus, much as other chunks\n> > of Git are copyrighted by Linus?\n>\n> The convention for xx.po, judging from the way template pot file\n> is written out, is to name the package's copyright holder, not\n> translation's, on that line. \n\nExactly. That line should say that even though I have been the author of \nde.po, I still assign copyright (or the assign-able parts of it) to the \npackage's copyright owner, which in this case is Linus. As Junio says, this \nis a suggestion from gettext, and I'd simply follow it here.\n\n> So Linus does not have to have anything to do with the German part, \n> but I think the appropriate name to place there is yours.\n\ns/yours/his/ ? Otherwise this sentence sounds like a contradiction to the \nprevious one...\n\nChristian\n"},{"id":"48132","messageId":"200707221424.20548.stimming@tuhh.de","threadId":"9108","inReplyTo":"20070722074525.GX32566@spearce.org","subject":"Re: [PATCH 2/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-22T12:24:20Z","receivedAt":"2007-07-22T12:24:20Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Sonntag, 22. Juli 2007 09:45 schrieb Shawn O. Pearce:\n> > Here I marked much more strings than in the previous patch, and as\n> > discussed the procedure [mc ...] is used for translation. \n>\n> Almost. I noticed two that you did miss, and its because they are\n> totally weird. We may want to rewrite this block of code first...\n\nYes, I've noticed those two run-time strings as well; I simply deferred them \nto be dealt with at a later point in time. As you already say, they will have \nto be rewritten before they can be translated. Probably an extra layer of \n[format ...] will do.\n\n> > @@ -1682,69 +1682,69 @@ trace add variable current_branch write\n> > \".mbar.repository entryconf [.mbar.repos .mbar.repository add separator\n> >\n> > .mbar.repository add command \\\n> > -\t-label {Visualize Current Branch's History} \\\n> > +\t-label [mc \"Visualize Current Branch's History\"] \\\n> > \t-command {do_gitk $current_branch}\n> > trace add variable current_branch write \".mbar.repository entryconf\n> > [.mbar.repository index last] -label \\\"Visualize \\$current_branch's\n> > History\\\" ;#\" .mbar.repository add command \\\n>\n> But they are in a double quoted string and will\n> be eval'd later by Tcl, so we actually need something like:\n>\n> - trace add variable current_branch write \".mbar.repository entryconf\n> [.mbar.repository index last] -label \\\"Visualize \\$current_branch's\n> History\\\" ;#\" + trace add variable current_branch write \".mbar.repository\n> entryconf [.mbar.repository index last] -label \\[mc \\\"Visualize\n> \\$current_branch's History\\\"\\] ;#\"\n\nErr... I didn't get the latter one, but as I said, this can be deferred until \nlater.\n\n> > -\t.mbar.apple add command -label \"About [appname]\" \\\n> > +\t.mbar.apple add command -label [mc \"About %s\" appname] \\\n>\n> Bug. This needs to be:\n>\n> +\t.mbar.apple add command -label [mc \"About %s\" [appname]] \\\n>\n> You lost one level of [] there when you did the replacement.\n\nOops, sorry, you are right. Also, I didn't test quite thoroughly after the \ns/_/mc/ replacement, compared to the original _ introduction, where I already \ncaught this one once before.\n\n> I only noticed this during a fast scan through while deleting text.\n> I'll have to reread this patch more carefully later, before I apply\n> (or merge) it, to make sure we don't have more such cases.\n\nThe appname thing was the only occurrence in this file, but it occurs several \ntimes.\n\nChristian\n"},{"id":"48135","messageId":"Pine.LNX.4.64.0707221344200.14781@racer.site","threadId":"9108","inReplyTo":"200707221416.42908.stimming@tuhh.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T12:44:58Z","receivedAt":"2007-07-22T12:44:58Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Christian Stimming wrote:\n\n> Am Sonntag, 22. Juli 2007 10:05 schrieb Junio C Hamano:\n> > \"Shawn O. Pearce\" writes:\n> > > Christian Stimming wrote:\n> > >> Subject: [PATCH] Initial German translation for testing of i18n.\n> > >> diff --git a/po/de.po b/po/de.po\n> > >> new file mode 100644\n> > >> index 0000000..0592836\n> > >> --- /dev/null\n> > >> +++ b/po/de.po\n> > >> @@ -0,0 +1,265 @@\n> > >> +# Translation of git-gui to German.\n> > >> +# Copyright (C) 2007 Linux Torvalds\n> > >\n> > > I didn't realize Linus wrote German. ;-)\n> > >\n> > > Or are you assigning the copyright to Linus, much as other chunks\n> > > of Git are copyrighted by Linus?\n> >\n> > The convention for xx.po, judging from the way template pot file\n> > is written out, is to name the package's copyright holder, not\n> > translation's, on that line. \n> \n> Exactly. That line should say that even though I have been the author of \n> de.po, I still assign copyright (or the assign-able parts of it) to the \n> package's copyright owner, which in this case is Linus. As Junio says, \n> this is a suggestion from gettext, and I'd simply follow it here.\n\nHow about Junio instead? Linus created Git, but Junio is the official \nmaintainer (by mutual agreement).\n\nCiao,\nDscho\n"},{"id":"48136","messageId":"200707221457.52542.stimming@tuhh.de","threadId":"9108","inReplyTo":"Pine.LNX.4.64.0707221344200.14781@racer.site","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-22T12:57:52Z","receivedAt":"2007-07-22T12:57:52Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Sonntag, 22. Juli 2007 14:44 schrieb Johannes Schindelin:\n> > > >> Subject: [PATCH] Initial German translation for testing of i18n.\n> > > >> diff --git a/po/de.po b/po/de.po\n> > > >> new file mode 100644\n> > > >> index 0000000..0592836\n> > > >> --- /dev/null\n> > > >> +++ b/po/de.po\n> > > >> @@ -0,0 +1,265 @@\n> > > >> +# Translation of git-gui to German.\n> > > >> +# Copyright (C) 2007 Linux Torvalds\n> > > >\n> > > > I didn't realize Linus wrote German. ;-)\n> > > >\n> > > > Or are you assigning the copyright to Linus, much as other chunks\n> > > > of Git are copyrighted by Linus?\n> > >\n> > > The convention for xx.po, judging from the way template pot file\n> > > is written out, is to name the package's copyright holder, not\n> > > translation's, on that line.\n> >\n> > Exactly. That line should say that even though I have been the author of\n> > de.po, I still assign copyright (or the assign-able parts of it) to the\n> > package's copyright owner, which in this case is Linus. As Junio says,\n> > this is a suggestion from gettext, and I'd simply follow it here.\n>\n> How about Junio instead? Linus created Git, but Junio is the official\n> maintainer (by mutual agreement).\n\nThen the copyright line should probably better read\n\nCopyright (C) 2007 Shawn Pearce, et al.\n\nbecause that's what the copyright for the other git-gui files say.\n\nChristian\n"},{"id":"48139","messageId":"Pine.LNX.4.64.0707221405550.14781@racer.site","threadId":"9108","inReplyTo":"200707221457.52542.stimming@tuhh.de","subject":"Re: [PATCH 3/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T13:06:52Z","receivedAt":"2007-07-22T13:06:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Christian Stimming wrote:\n\n> Am Sonntag, 22. Juli 2007 14:44 schrieb Johannes Schindelin:\n>\n> > [Christian, I think, wrote]\n> >\n> > > That line should say that even though I have been the author of \n> > > de.po, I still assign copyright (or the assign-able parts of it) to \n> > > the package's copyright owner, which in this case is Linus. As Junio \n> > > says, this is a suggestion from gettext, and I'd simply follow it \n> > > here.\n> >\n> > How about Junio instead? Linus created Git, but Junio is the official\n> > maintainer (by mutual agreement).\n> \n> Then the copyright line should probably better read\n> \n> Copyright (C) 2007 Shawn Pearce, et al.\n> \n> because that's what the copyright for the other git-gui files say.\n\nOops. Yes, of course.\n\nCiao,\nDscho\n"},{"id":"48140","messageId":"200707221516.29634.stimming@tuhh.de","threadId":"9108","inReplyTo":"85tzrxr0m9.fsf@lola.goethe.zz","subject":"Re: German translations","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-22T13:16:29Z","receivedAt":"2007-07-22T13:16:29Z","isPatch":false,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Samstag, 21. Juli 2007 21:57 schrieb David Kastrup:\n> > Thanks for additional word proposals. I'll discuss these and the two\n> > followups in German below.\n> >\n> >> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134\n> >> > +msgid \"Commit\"\n> >> > +msgstr \"Übertragen\"\n> >>\n> >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein\n> >> passendes Substantiv zu finden. \"Sendung\"?\n> >\n> > Ich habe im Glossar \"übertragen (senden?, übergeben?)\". .\n>\n> Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.\n> Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.\n\nEinspielen und Einspielung sind auch Möglichkeiten, aber bisher finde ich das \nnoch nicht überzeugender als die Übertragung. \n\nFür was ist Ausspielung gemeint? Checkout? Für mich klingt \nausspielen/Ausspielung hauptsächlich nach einer Pokerrunde (oder eher \ndestruktiv, \"dieser Mitarbeiter hat im Projekt wirklich ausgespielt\") und \nnicht nach dem Ablegen in Akten oder dem Rüberschicken zum Archiv-Server. \nAber stimmt, \"checkout\" braucht noch einen Begriff und bisher habe ich auch \nkeinen überzeugenden Vorschlag.\n\n> > Deswegen wird was anderes benötigt. Für fetch und pull gleichermaßen\n> > würden holen/ziehen/übernehmen gehen und man muss sich halt auf eine\n> > Zuordnung festlegen.\n>\n> fetch = anfordern, pull = übernehmen?\n\nKlingt gut, ok, vielen Dank.\n\n> >> > +#: git-gui.sh:1632 git-gui.sh:2140\n> >> > +msgid \"Push\"\n> >> > +msgstr \"Schieben\"\n> >\n> > Glossar: \"schieben (hochladen? verschicken?)\"\n>\n> Ausliefern? Durchgeben?\n\nAusliefern ist gut, danke.\n\n> >> > +#: git-gui.sh:1641\n> >> > +msgid \"Browse Current Branch\"\n> >> > +msgstr \"Aktuellen Zweig durchblättern\"\n> >>\n> >> Im aktuellen Zweig stöbern.\n> >\n> > stöbern für \"to browse\"? Das ist aber definitiv nicht das, was\n> > normalerweise als Übersetzung von \"to browse\" gewählt wird. Da ist\n> > man eben bei blättern.\n>\n> Aber das wäre \"leafing through\" und ist eben auf Bücher beschränkt.\n\nVon den Büchern kommt die Bedeutung her, ja, aber browse und leafing through \nsind halt beide ein blättern, da sehe ich keinen Widerspruch zur möglichen \nVerwendung hier.\n\n> \"wühlen\" wäre flapsig. Etwas\n> hochsprachlicher wäre noch \"durchforsten\", aber das trägt uns\n> natürlich den Zorn der Förster für den Begriffsmißbrauch zu.\n> \"erkunden\" wäre auch noch möglich.\n\nBeim Erkunden fehlt mir die Bedeutung, dass man da einzelne Schritte einen \nnach dem anderen durchgehen kann. Das finde ich im Blättern weiterhin am \nbesten wiederzuerkennen. Dann noch eher durchforsten als erkunden.\n\n> >> > David Kastrup wrote:\n> >> >>> +#: git-gui.sh:1798 git-gui.sh:2130 git-gui.sh:2228\n> >> >>> +msgid \"Sign Off\"\n> >> >>> +msgstr \"Freizeichnen\"\n> >> >>\n> >> >> Gegenzeichnen?\n> >> >\n> >> > Abzeichnen!\n> >>\n> >> Absegnen.  Ich denke mal, in der Form mit \"Ab\" ist das dermaßen\n> >> gebräuchlich, daß man damit keine religiösen Befindlichkeiten\n> >> verletzt.\n> >>\n> >> Ansonsten: Abnicken oder Gutheißen.\n> >\n> > Absegnen ist zu flapsig, Abnicken und Gutheißen erst recht.\n>\n> Abnicken ja, aber Gutheißen ist nun wirklich ein hochsprachlicher\n> Begriff.\n>\n> > Abzeichnen wäre okay, aber das ist Freizeichnen auch.\n>\n> Freizeichnen ist viel zu nischensprachlich. Mit Abzeichnen könnte ich\n> leben, obwohl ich Gutheißen besser fände.\n\nAbzeichnen ist ok.\n\nAm Samstag, 21. Juli 2007 22:09 schrieb David Kastrup:\n> After a view of the glossary:\n>\n> \"amend\" \"ergänzen\"\n> ist nicht ganz korrekt. \"nachbessern\" wäre da erheblich besser.\n\nOk.\n\n> \"message\" würde ich als \"Nachricht\" statt \"Meldung\" übersetzen.\n\nIrgendwie Geschmackssache. Man muss sich das ein bisschen im Kontext \nvorstellen: \"Die Meldung zur Einspielung/Übertragung\", \"Die Nachricht zur \nEinspielung/Übertragung\", ich würde da erstmal bei Meldung bleiben.\n\n> \"revert\" \"zurückkehren\" würde ich eher als \"revidieren\" oder\n> \"aufheben\" bezeichnen.\n\n\"revidieren\" ist gut.\n\n> \"revision\" ist wohl schlicht eine \"Version\" statt der \"Revision\", die\n> einem das Finanzamt ins Haus bringt.\n\nAuch das ist gut, allerdings frage ich mich natürlich auch, warum das Dingens \ndann nicht auch gleich auf Englisch \"version\" heißt :-)\n\nBisheriger Zwischenstand wird im glossary.csv nachgetragen; zur Anpassung von \nde.po hab ich noch keine Zeit gehabt, kommt aber sobald neue Strings drin \nsind.\n\nChristian\n"},{"id":"48141","messageId":"200707221535.46422.stimming@tuhh.de","threadId":"9108","inReplyTo":"7vabtpv43d.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-22T13:35:46Z","receivedAt":"2007-07-22T13:35:46Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:\n> > Agreed. I propose to throw away the \"add glossary\" patch and I'll\n> > resubmit, this time in a separate po/glossary/ directory, where each\n> > language will get a po file for the glossary.\n>\n> Actually, I would even suggest that we should NOT have a\n> separate glossary file at all, if gettext suite allows what I\n> outline below.\n>\n> How about having it as a part of header comment in each of the\n> xx.po file?\n\nI don't think this would work well. In particular, you don't get all the nice \ngettext *merging* features that you only get with a full-blown po file.\n\n> The division of labor I think would make sense for message l10n\n> process goes like this:\n>\n> - The software developer (primarily Shawn): responsible for\n> marking messages subject to i18n;\n\nYes, except those developers who don't happen to be translators as well tend \nto forget the markups. I don't blame anyone for doing so - just keep in mind \nthat translators have to give feedback about missing markups, and they \nhopefully will do so.\n\n> - The i18n coordinator (could be Shawn but anybody else can\n> volunteer; as things stand, I think Christian and Johannes\n> are doing this): responsible for running \"make\n> po/git-gui.pot; make update-po\" from time to time in order to\n> keep po/*.po in sync with the vocabulary.\n\nActually, please DO NOT RUN update-po except right before a new tarball is \nbeing packaged and distributed! It sucks royally if I have updated my de.po \ntranslation, only to discover someone has run update-po on the server and I \nhave to figure out how to get out of the de.po conflicts. There will be \nconflicts after each and every update-po because the line numbers in the po \nfile will have changed inevitably -- but the actualy content in terms of \nmessages might be completely unchanged.\n\nFor that reason, please use the update-po rule AS SELDOM AS POSSIBLE. Thanks a \nlot.\n\n> initially, populate \"glossary\" part in po/git-gui.pot;\n>\n> as needed, add entries \"glossary\" part in po/git-gui.pot, and\n> (if possible) add corresponding placeholders to po/*.po;\n\nAgain, this doesn't work well, and depending on the po file editor that is \nused by a translator they might not see this comment block anyway. I would \ninstead propose a subdirectory po/glossary; a CSV file that contains the \nterms itself; a csv-to-po converter script that will turn the terms into a \ngit-gui-glossary.pot; and a po file for each language.\n\n> - Translators (one for each language): responsible for updating\n> po/xx.po file;\n>\n> initially, start by copying po/git-gui.pot to create\n> po/xx.po;\n>\n> maintainance of \"glossary\" part of po/xx.po could also be\n> made this person's responsibility instead of i18n\n> coordinator's.\n>\n> This way, the translators do not have to be so familiar with the\n> gettext toolchain nor even have to have gettext installed.\n\nTranslators who are unfamiliar with gettext are a mixed blessing. Anyone is \nable to contribute a bunch of initial string translations, especially if \nthere hasn't been a translation before. But if someone or a team wants to \nachieve a really *high-quality*, 100%, consistent, and understandable \ntranslation, the translators must be able to test the translation a lot, \nwhich implies they must be able to generate the .msg files, which requires \nthe gettext toolchain anyway. For that reason I wouldn't spent too much \neffort to enable translation work without gettext tools; instead, I'd rather \nencourage to optimize the setup for those translators that have the full \ntoolchain available.\n\nChristian\n"},{"id":"48143","messageId":"Pine.LNX.4.64.0707221526080.14781@racer.site","threadId":"9108","inReplyTo":"200707221535.46422.stimming@tuhh.de","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-22T14:29:37Z","receivedAt":"2007-07-22T14:29:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Jul 2007, Christian Stimming wrote:\n\n> Am Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:\n>\n> > - The i18n coordinator (could be Shawn but anybody else can\n> > volunteer; as things stand, I think Christian and Johannes\n> > are doing this): responsible for running \"make\n> > po/git-gui.pot; make update-po\" from time to time in order to\n> > keep po/*.po in sync with the vocabulary.\n> \n> Actually, please DO NOT RUN update-po except right before a new tarball \n> is being packaged and distributed! It sucks royally if I have updated my \n> de.po translation, only to discover someone has run update-po on the \n> server and I have to figure out how to get out of the de.po conflicts.\n\nI plan to work on that. It seems to be pretty easy to define a sane merge \nbehaviour, and we have gitattributes: by setting \"*.po diff=po merge=po\" \nwe can provide a custom merge program, just for .po files.\n\n> > - Translators (one for each language): responsible for updating\n> > po/xx.po file;\n> >\n> > initially, start by copying po/git-gui.pot to create\n> > po/xx.po;\n> >\n> > maintainance of \"glossary\" part of po/xx.po could also be\n> > made this person's responsibility instead of i18n\n> > coordinator's.\n> >\n> > This way, the translators do not have to be so familiar with the\n> > gettext toolchain nor even have to have gettext installed.\n> \n> Translators who are unfamiliar with gettext are a mixed blessing. [...] \n> I wouldn't spent too much effort to enable translation work without \n> gettext tools; instead, I'd rather encourage to optimize the setup for \n> those translators that have the full toolchain available.\n\nYou need not work on the \"without gettext toolchain\" part; I will. Let's \nsee how far I get ;-)\n\nCiao,\nDscho\n"},{"id":"48144","messageId":"20070722165232.30e01005.froese@gmx.de","threadId":"9108","inReplyTo":"85tzrxr0m9.fsf@lola.goethe.zz","subject":"Re: German translations","fromName":"Edgar Toernig","fromEmail":"froese@gmx.de","sentAt":"2007-07-22T14:52:32Z","receivedAt":"2007-07-22T14:52:32Z","isPatch":false,"sender":{"key":"froese@gmx.de","avatar":null},"body":"> >> > +#: git-gui.sh:1627 git-gui.sh:1802 git-gui.sh:2134\n> >> > +msgid \"Commit\"\n> >> > +msgstr \"Übertragen\"\n> >>\n> >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein\n> >> passendes Substantiv zu finden. \"Sendung\"?\n> [...]\n> Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.\n> Symmetrisch, verständlich, als Verb und Substantiv zu gebrauchen.\n>\n> [usw]\n\nDas ist genau der Grund, warum ich normalerweise keine deutschen\nLokalisierungen benutze - total unverstaendlicher Kauderwelsch.\n\nDenkt doch bitte mal an die Zielgruppe! Das sind Techniker, keine\nGrossmuetter. Ihr duerft Fachvokabular benutzen! Und gerade hier\nwird die Zielgruppe schon englische Dokumentation gelesen haben.\nSolch zwanghaft eingedeutschten Begriffe verwirren da nur.\nAlso sagt doch bitte einfach \"der Commit\" und \"comitten\" wie es\njeder Techniker macht. Ihr duerft auch \"das Repository\", \"der\nIndex\" und mMn auch ruhig \"der Branch\" benutzen.\n\nVerstaendlichkeit, Klarheit, Exaktheit - das ist das oberste Ziel!\nWir sind doch keine Franzosen ;-)\n\nCiao, ET.\n\n\nPS: bzgl. \"Sign Off\": \"Gutheißen\" ist zu lasch - das entspricht\n dem Ack'ed-by.\n"},{"id":"48336","messageId":"200707232120.32963.stimming@tuhh.de","threadId":"9108","inReplyTo":"20070722165232.30e01005.froese@gmx.de","subject":"Re: German translations","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-23T19:20:32Z","receivedAt":"2007-07-23T19:20:32Z","isPatch":false,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Sonntag, 22. Juli 2007 16:52 schrieb Edgar Toernig:\n> > >> > +msgid \"Commit\"\n> > >> > +msgstr \"Übertragen\"\n> > >>\n> > >> Einpflegen ist als Verb gebräuchlich, aber dann ist es schwer, ein\n> > >> passendes Substantiv zu finden. \"Sendung\"?\n> >\n> > Ich habe was: Einspielen, Ausspielen, Einspielung, Ausspielung.\n>\n> Das ist genau der Grund, warum ich normalerweise keine deutschen\n> Lokalisierungen benutze - total unverstaendlicher Kauderwelsch.\n>\n> Denkt doch bitte mal an die Zielgruppe! \n\nJa, genau das sag ich doch.\n\n> Das sind Techniker, keine \n> Grossmuetter. Ihr duerft Fachvokabular benutzen! Und gerade hier\n> wird die Zielgruppe schon englische Dokumentation gelesen haben.\n\nNein. Die Zielgruppe der deutschen Übersetzung sind jene Techniker, die \npartout mit Englisch auf Kriegsfuß stehen. Jaja, solche gibt es. Und für \nsolche muss man überlegen, ob es deutsche Begriffe gibt, die man in der \ngleichen Bedeutung verwenden kann. Das geht nicht so spontan - also bitte \nerstmal abwarten und selber überlegen. Die englischen Begriffe sind als \nfallback immer noch möglich, aber erstmal wird überlegt.\n\nIch bin auch für Anregungen dankbar, wie andere Übersetzer das denn gelöst \nhaben. Das erwähnte TortoiseSVN mit einer IMHO gelungenen deutschen Doku hat \ncommit=übertragen gewählt, ist aber bei checkout=auschecken geblieben. Die \nanderen SVN-Clients, bei denen man einen deutsche Übersetzung sehen kann, \nbieten da leider nur mindere Qualität und haben praktisch sämtliche \nSchlüsselworte auf Englisch gelassen.\n\n> Solch zwanghaft eingedeutschten Begriffe verwirren da nur.\n> Also sagt doch bitte einfach \"der Commit\" und \"comitten\" wie es\n> jeder Techniker macht. Ihr duerft auch \"das Repository\", \"der\n> Index\" und mMn auch ruhig \"der Branch\" benutzen.\n\nNein. Wenn dir diese englischen Begriffe lieber sind, dann bleib gerne bei \nLANG=C bzw. en und fertig. Hier wird erstmal diskutiert, ob sich nicht doch \ndeutsche Begriffe finden lassen. Es ist ja nicht so, als ob hier das \nallererste Mal ein SCM auf deutsch erklärt werden müsste.\n\n> Verstaendlichkeit, Klarheit, Exaktheit - das ist das oberste Ziel!\n\n- der deutschen Übersetzung, richtig! Wer das mit den englischen Begriffen \nerreichen will, bleibt bei LANG=C.\n\n> PS: bzgl. \"Sign Off\": \"Gutheißen\" ist zu lasch - das entspricht\n> dem Ack'ed-by.\n\nIch finde da den Vorschlag \"abzeichnen\" bisher am besten.\n\nGruß\n\nChristian\n"},{"id":"48337","messageId":"200707232123.01682.stimming@tuhh.de","threadId":"9108","inReplyTo":"20070722073806.GW32566@spearce.org","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-23T19:23:01Z","receivedAt":"2007-07-23T19:23:01Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Am Sonntag, 22. Juli 2007 09:38 schrieb Shawn O. Pearce:\n> > +## Internationalization (i18n) through msgcat and gettext. See\n> > +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html\n> > +package require msgcat\n> > +::msgcat::mcload [file join $oguilib msgs]\n> > +namespace import ::msgcat::mc\n>\n> Thanks. We'll probably also want to modify the lib/class.tcl to\n> import ::msgcat::mc into the class namespace when it creates it.\n> I use that class thing throught most of git-gui, especially for\n> UI code. About 50% of git-gui has been converted to use class,\n> the other 50% is just global and is still in git-gui.sh. ;-)\n\nAs I was adding the markup in all the other files, I didn't have to add \nanother import statement anywhere else. Seems like the global mc procedure \nworks just fine.\n\nIn other words, if you think the mc procedure should be imported in another \nplace as well, please do so because I don't know your future plans with class \nstructure (and I also don't need to know for adding the i18n support right \nnow).\n\nThanks,\n\nChristian\n"},{"id":"48343","messageId":"200707232216.40300.stimming@tuhh.de","threadId":"9108","inReplyTo":"7vabtpv43d.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Add glossary that can be converted into a po file for each language.","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-23T20:16:39Z","receivedAt":"2007-07-23T20:16:39Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Signed-off-by: Christian Stimming \n---\n\nAm Samstag, 21. Juli 2007 23:28 schrieb Junio C Hamano:\n> >> I would suggest having one glossary file per language.\n> >\n> > Agreed. I propose to throw away the \"add glossary\" patch and I'll\n> > resubmit, this time in a separate po/glossary/ directory, where each\n> > language will get a po file for the glossary.\n>\n> Actually, I would even suggest that we should NOT have a\n> separate glossary file at all, if gettext suite allows what I\n> outline below.\n>\n> How about having it as a part of header comment in each of the\n> xx.po file?\n\nAs I already wrote: Having a glossary in the header of the po file has \nsome (IMHO serious) drawbacks. For that reason I've pushed this patch\nto the mob branch: It contains one tab-separated text file with the relevant\nterms *plus their definition* (for now, pulled from \ngit/Documentation/glossary.txt). As an example, you also see the German\nglossary translation - and having the definition available there as well (and \nhaving it updated by running make update-po) is indeed a huge advantage.\n\n po/glossary/Makefile | 9 ++\n po/glossary/de.po | 151 ++++++++++++++++++++++++++++++++++++++\n po/glossary/git-gui-glossary.txt | 34 +++++++++\n po/glossary/txt-to-pot.sh | 48 ++++++++++++\n 4 files changed, 242 insertions(+), 0 deletions(-)\n create mode 100644 po/glossary/Makefile\n create mode 100644 po/glossary/de.po\n create mode 100644 po/glossary/git-gui-glossary.txt\n create mode 100755 po/glossary/txt-to-pot.sh\n\ndiff --git a/po/glossary/Makefile b/po/glossary/Makefile\nnew file mode 100644\nindex 0000000..749aa2e\n--- /dev/null\n+++ b/po/glossary/Makefile\n@@ -0,0 +1,9 @@\n+PO_TEMPLATE = git-gui-glossary.pot\n+\n+ALL_POFILES = $(wildcard *.po)\n+\n+$(PO_TEMPLATE): $(subst .pot,.txt,$(PO_TEMPLATE))\n+\t./txt-to-pot.sh $< > $@\n+\n+update-po:: git-gui-glossary.pot\n+\t$(foreach p, $(ALL_POFILES), echo Updating $p ; msgmerge -U $p $(PO_TEMPLATE) ; )\ndiff --git a/po/glossary/de.po b/po/glossary/de.po\nnew file mode 100644\nindex 0000000..0d07f68\n--- /dev/null\n+++ b/po/glossary/de.po\n@@ -0,0 +1,151 @@\n+# Translation of git-gui glossary to German\n+# Copyright (C) 2007 Shawn Pearce, et al.\n+# This file is distributed under the same license as the git package.\n+# Christian Stimming , 2007\n+#\n+msgid \"\"\n+msgstr \"\"\n+\"Project-Id-Version: git-gui glossary\\n\"\n+\"PO-Revision-Date: 2007-07-23 22:07+0200\\n\"\n+\"Last-Translator: Christian Stimming \\n\"\n+\"Language-Team: German \\n\"\n+\"MIME-Version: 1.0\\n\"\n+\"Content-Type: text/plain; charset=UTF-8\\n\"\n+\"Content-Transfer-Encoding: 8bit\\n\"\n+\n+#. \"English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)\"\n+msgid \"\"\n+\"English Term (Dear translator: This file will never be visible to the user!)\"\n+msgstr \"Deutsche Übersetzung\"\n+\n+#. \"\"\n+msgid \"amend\"\n+msgstr \"nachbessern (ergänzen)\"\n+\n+#. \"\"\n+msgid \"annotate\"\n+msgstr \"annotieren\"\n+\n+#. \"A 'branch' is an active line of development.\"\n+msgid \"branch [noun]\"\n+msgstr \"Zweig\"\n+\n+#. \"\"\n+msgid \"branch [verb]\"\n+msgstr \"verzweigen\"\n+\n+#. \"\"\n+msgid \"checkout [noun]\"\n+msgstr \"Auscheck? Ausspielung? Abruf?\"\n+\n+#. \"The action of updating the working tree to a revision which was stored in the object database.\"\n+msgid \"checkout [verb]\"\n+msgstr \"auschecken? ausspielen? abrufen?\"\n+\n+#. \"A single point in the git history.\"\n+msgid \"commit [noun]\"\n+msgstr \"Übertragung (Sendung?, Übergabe?, Einspielung?, Ablagevorgang?)\"\n+\n+#. \"The action of storing a new snapshot of the project's state in the git history.\"\n+msgid \"commit [verb]\"\n+msgstr \"übertragen (senden?, übergeben?, einspielen?, einpflegen?, ablegen?)\"\n+\n+#. \"\"\n+msgid \"diff [noun]\"\n+msgstr \"Vergleich\"\n+\n+#. \"\"\n+msgid \"diff [verb]\"\n+msgstr \"vergleichen\"\n+\n+#. \"A fast-forward is a special typ of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have.\"\n+msgid \"fast forward merge\"\n+msgstr \"Schnellzusammenführung\"\n+\n+#. \"Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too.\"\n+msgid \"fetch\"\n+msgstr \"anfordern (holen?)\"\n+\n+#. \"A collection of files. The index is a stored version of your working tree.\"\n+msgid \"index (in git-gui: staging area)\"\n+msgstr \"Bereitstellung\"\n+\n+#. \"A successful merge results in the creation of a new commit representing the result of the merge.\"\n+msgid \"merge [noun]\"\n+msgstr \"Zusammenführung\"\n+\n+#. \"To bring the contents of another branch into the current branch.\"\n+msgid \"merge [verb]\"\n+msgstr \"zusammenführen\"\n+\n+#. \"\"\n+msgid \"message\"\n+msgstr \"Meldung (Nachricht?)\"\n+\n+#. \"Pulling a branch means to fetch it and merge it.\"\n+msgid \"pull\"\n+msgstr \"übernehmen (ziehen?)\"\n+\n+#. \"Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)\"\n+msgid \"push\"\n+msgstr \"ausliefern (hochladen? verschicken? schieben?)\"\n+\n+#. \"\"\n+msgid \"redo\"\n+msgstr \"wiederholen\"\n+\n+#. \"A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)\"\n+msgid \"repository\"\n+msgstr \"Projektarchiv\"\n+\n+#. \"\"\n+msgid \"reset\"\n+msgstr \"zurücksetzen\"\n+\n+#. \"\"\n+msgid \"revert\"\n+msgstr \"revidieren (aufheben?, zurückkehren?)\"\n+\n+#. \"A particular state of files and directories which was stored in the object database.\"\n+msgid \"revision\"\n+msgstr \"Version? Revision?\"\n+\n+#. \"\"\n+msgid \"sign off\"\n+msgstr \"abzeichnen (gegenzeichnen?, freizeichnen?, absegnen?)\"\n+\n+#. \"\"\n+msgid \"staging area\"\n+msgstr \"Bereitstellung\"\n+\n+#. \"\"\n+msgid \"status\"\n+msgstr \"Status\"\n+\n+#. \"A ref pointing to a tag or commit object\"\n+msgid \"tag [noun]\"\n+msgstr \"Markierung\"\n+\n+#. \"\"\n+msgid \"tag [verb]\"\n+msgstr \"markieren\"\n+\n+#. \"A regular git branch that is used to follow changes from another repository.\"\n+msgid \"tracking branch\"\n+msgstr \"? Entfernter Zweig? Folgezweig?\"\n+\n+#. \"\"\n+msgid \"undo\"\n+msgstr \"rückgängig\"\n+\n+#. \"\"\n+msgid \"update\"\n+msgstr \"aktualisieren\"\n+\n+#. \"\"\n+msgid \"verify\"\n+msgstr \"überprüfen\"\n+\n+#. \"The tree of actual checked out files.\"\n+msgid \"working copy, working tree\"\n+msgstr \"Arbeitskopie\"\ndiff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt\nnew file mode 100644\nindex 0000000..e079bb2\n--- /dev/null\n+++ b/po/glossary/git-gui-glossary.txt\n@@ -0,0 +1,34 @@\n+\"English Term (Dear translator: This file will never be visible to the user!)\"\t\"English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)\"\n+\"amend\"\t\"\"\n+\"annotate\"\t\"\"\n+\"branch [noun]\"\t\"A 'branch' is an active line of development.\"\n+\"branch [verb]\"\t\"\"\n+\"checkout [noun]\"\t\"\"\n+\"checkout [verb]\"\t\"The action of updating the working tree to a revision which was stored in the object database.\"\n+\"commit [noun]\"\t\"A single point in the git history.\"\n+\"commit [verb]\"\t\"The action of storing a new snapshot of the project's state in the git history.\"\n+\"diff [noun]\"\t\"\"\n+\"diff [verb]\"\t\"\"\n+\"fast forward merge\"\t\"A fast-forward is a special typ of merge where you have a revision and you are merging another branch's changes that happen to be a descendant of what you have.\"\n+\"fetch\"\t\"Fetching a branch means to get the branch's head from a remote repository, to find out which objects are missing from the local object database, and to get them, too.\"\n+\"index (in git-gui: staging area)\"\t\"A collection of files. The index is a stored version of your working tree.\"\n+\"merge [noun]\"\t\"A successful merge results in the creation of a new commit representing the result of the merge.\"\n+\"merge [verb]\"\t\"To bring the contents of another branch into the current branch.\"\n+\"message\"\t\"\"\n+\"pull\"\t\"Pulling a branch means to fetch it and merge it.\"\n+\"push\"\t\"Pushing a branch means to get the branch's head ref from a remote repository, and ... (well, can someone please explain it for mere mortals?)\"\n+\"redo\"\t\"\"\n+\"repository\"\t\"A collection of refs (?) together with an object database containing all objects which are reachable from the refs... (oops, you've lost me here. Again, please an explanation for mere mortals?)\"\n+\"reset\"\t\"\"\n+\"revert\"\t\"\"\n+\"revision\"\t\"A particular state of files and directories which was stored in the object database.\"\n+\"sign off\"\t\"\"\n+\"staging area\"\t\"\"\n+\"status\"\t\"\"\n+\"tag [noun]\"\t\"A ref pointing to a tag or commit object\"\n+\"tag [verb]\"\t\"\"\n+\"tracking branch\"\t\"A regular git branch that is used to follow changes from another repository.\"\n+\"undo\"\t\"\"\n+\"update\"\t\"\"\n+\"verify\"\t\"\"\n+\"working copy, working tree\"\t\"The tree of actual checked out files.\"\ndiff --git a/po/glossary/txt-to-pot.sh b/po/glossary/txt-to-pot.sh\nnew file mode 100755\nindex 0000000..8a8f976\n--- /dev/null\n+++ b/po/glossary/txt-to-pot.sh\n@@ -0,0 +1,48 @@\n+#!/bin/sh\n+# This is a very, _very_, simple script to convert a tab-separated\n+# .txt file into a .pot/.po.\n+# Its not clever but it took me 2 minutes to write :)\n+# Michael Twomey \n+# 23 March 2001\n+# with slight GnuCash modifications by Christian Stimming \n+# 19 Aug 2001, 23 Jul 2007\n+\n+#check args\n+if [ $# -eq 0 ]\n+then\n+\tcat < git-gui-glossary.pot\n+!\n+\texit 1;\n+fi\n+\n+GLOSSARY_CSV=\"$1\";\n+\n+if [ ! -f \"$GLOSSARY_CSV\" ]\n+then\n+\techo \"Can't find $GLOSSARY_CSV.\";\n+\texit 1;\n+fi\n+\n+cat <, YEAR.\n+#\n+#, fuzzy\n+msgid \"\"\n+msgstr \"\"\n+\"Project-Id-Version: PACKAGE VERSION\\n\"\n+\"POT-Creation-Date: `date +'%Y-%m-%d %H:%M%z'`\\n\"\n+\"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\\n\"\n+\"Last-Translator: FULL NAME \\n\"\n+\"Language-Team: LANGUAGE \\n\"\n+\"MIME-Version: 1.0\\n\"\n+\"Content-Type: text/plain; charset=CHARSET\\n\"\n+\"Content-Transfer-Encoding: ENCODING\\n\"\n+\n+!\n+\n+#Yes this is the most simple awk script you've ever seen :)\n+awk -F'\\t' '{if ($2 != \"\") print \"#. \"$2; print \"msgid \"$1; print \"msgstr \\\"\\\"\\n\"}' \\\n+$GLOSSARY_CSV\n-- \n1.5.2\n"},{"id":"48391","messageId":"7v7ioqlggt.fsf@assigned-by-dhcp.cox.net","threadId":"9108","inReplyTo":"200707232216.40300.stimming@tuhh.de","subject":"Re: [PATCH] Add glossary that can be converted into a po file for each language.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-24T01:48:18Z","receivedAt":"2007-07-24T01:48:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Stimming writes:\n\n> As I already wrote: Having a glossary in the header of the po file has \n> some (IMHO serious) drawbacks.\n\nYeah, that was me talking without knowing what are the usual\nworkflows with gettext toolchain. A separate glossary that\nproperly is PO is much nicer. We could even use that in the\nhelp text.\n"},{"id":"48400","messageId":"7vk5sqi91m.fsf@assigned-by-dhcp.cox.net","threadId":"9108","inReplyTo":"200707232216.40300.stimming@tuhh.de","subject":"Re: [PATCH] Add glossary that can be converted into a po file for each language.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-24T06:56:53Z","receivedAt":"2007-07-24T06:56:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Christian Stimming writes:\n\n> diff --git a/po/glossary/git-gui-glossary.txt b/po/glossary/git-gui-glossary.txt\n> new file mode 100644\n> index 0000000..e079bb2\n> --- /dev/null\n> +++ b/po/glossary/git-gui-glossary.txt\n> @@ -0,0 +1,34 @@\n> +\"English Term (Dear translator: This file will never be visible to the user!)\"\t\"English Definition (Dear translator: This file will never be visible to the user! It should only serve as a tool for you, the translator. Nothing more.)\"\n> +\"amend\"\t\"\"\n> +\"annotate\"\t\"\"\n> +\"branch [noun]\"\t\"A 'branch' is an active line of development.\"\n> +\"branch [verb]\"\t\"\"\n> +\"checkout [noun]\"\t\"\"\n> +\"checkout [verb]\"\t\"The action of updating the working tree to a revision which was stored in the object database.\"\n> +\"commit [noun]\"\t\"A single point in the git history.\"\n\nI wonder.... couldn't this be written as a Tcl array that maps\nword to its definition, marked with [mc] 'gettext'ese, perhaps,\nglossary.tcl? Then perhaps git-gui can include it and have a\nuser-visible glossary as part of its help system.\n\nAm I dreaming, or too drunk?\n"},{"id":"48420","messageId":"20070724113435.gd8xunvbk8o4wsss@webmail.tu-harburg.de","threadId":"9108","inReplyTo":"7vk5sqi91m.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Add glossary that can be converted into a po file for each language.","fromName":"Christian Stimming","fromEmail":"stimming@tuhh.de","sentAt":"2007-07-24T09:34:35Z","receivedAt":"2007-07-24T09:34:35Z","isPatch":true,"sender":{"key":"stimming@tuhh.de","avatar":"https://avatars.githubusercontent.com/u/227778?v=4"},"body":"Quoting Junio C Hamano :\n>> +++ b/po/glossary/git-gui-glossary.txt\n>> @@ -0,0 +1,34 @@\n>> +\"English Term (Dear translator: This file will never be visible to \n>> the user!)\"\t\"English Definition (Dear translator: This file will \n>> never be visible to the user! It should only serve as a tool for \n>> you, the translator. Nothing more.)\"\n>> +\"amend\"\t\"\"\n>> +\"annotate\"\t\"\"\n>> +\"branch [noun]\"\t\"A 'branch' is an active line of development.\"\n>> +\"branch [verb]\"\t\"\"\n>> +\"checkout [noun]\"\t\"\"\n>> +\"checkout [verb]\"\t\"The action of updating the working tree to a \n>> revision which was stored in the object database.\"\n>> +\"commit [noun]\"\t\"A single point in the git history.\"\n>\n> I wonder.... couldn't this be written as a Tcl array that maps\n> word to its definition, marked with [mc] 'gettext'ese, perhaps,\n> glossary.tcl? Then perhaps git-gui can include it and have a\n> user-visible glossary as part of its help system.\n\nI'm not so sure about this idea. I'd expect the glossary definitions \nfor the translators to emphasize other issues than what a user-visible \nglossary would explain. For the user, the glossary should explain what \neach term means and what the user can *do* with this. For the \ntranslator, the glossary should explain what each term means and where \nit appears in the project (and which other terms it should be \ndistinguished from). Also, the translator glossary IMHO should collect \nwarnings about potential ambiguities as well (including the very clear \ndistinction between noun and verb). Whereas the user glossary is \nprobably much more verbose in what it explains, but doesn't emphasize \nas much the clear differences between verb and noun and so on.\n\n> Am I dreaming, or too drunk?\n\nYou tell me :-)\n\nChristian\n"},{"id":"48477","messageId":"20070724145716.GL32566@spearce.org","threadId":"9108","inReplyTo":"200707232123.01682.stimming@tuhh.de","subject":"Re: [PATCH 1/5] Internationalization of git-gui","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-24T14:57:16Z","receivedAt":"2007-07-24T14:57:16Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Christian Stimming wrote:\n> Am Sonntag, 22. Juli 2007 09:38 schrieb Shawn O. Pearce:\n> > > +## Internationalization (i18n) through msgcat and gettext. See\n> > > +## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html\n> > > +package require msgcat\n> > > +::msgcat::mcload [file join $oguilib msgs]\n> > > +namespace import ::msgcat::mc\n> >\n> > Thanks. We'll probably also want to modify the lib/class.tcl to\n> > import ::msgcat::mc ...\n> \n> As I was adding the markup in all the other files, I didn't have to add \n> another import statement anywhere else. Seems like the global mc procedure \n> works just fine.\n> \n> In other words, if you think the mc procedure should be imported in another \n> place as well, please do so because I don't know your future plans with class \n> structure (and I also don't need to know for adding the i18n support right \n> now).\n\nHmm. Actually that makes sense. We probably don't need to make\nany changes, other than to make sure we don't override the \"mc\"\ndefinition in any of the other UI namespaces, since it is currently\nbeing inherited from :: (the global namespace).\n\nThanks.\n\n-- \nShawn.\n"}]}