Re: [PATCH] l10n: de.po: translate index as Index
Am Montag, 1. Juni 2015, 09:38:37 schrieb g...@drmicha.warpmail.net: Ralf Thielow venit, vidit, dixit 29.05.2015 20:54: The term index is translated as Staging-Area to not confuse beginners who don't know about Git's index. Since the term staging area doesn't appear in original Git messages (not even in the glossary) and index is a well known term for experienced users, we should treat index as a Git term and therefore don't translate it. Super! :) Sorry to contradict, but: No, not super. Again I question the whole point of such a denglish translation. Do you want to present the git wording to those experienced users who know git anyway? Then you are probably better off suggesting those guys to stick to the original English messages. Or do you want to describe what's going on in a language that somewhat resembles understandable German? In that case, Index is a particularly bad choice to keep as an unchanged word. To make things even worse, index is a particularly bad wording choice in English in the first place. Why? Because the e.g. git book of course has an index: That's the page where you can look up certain keywords that will then reference you to the place where those words are being used. It never occurred to me why anyone on earth ever thought this word might give a good metaphor for what it should mean in the git context. Well, maybe some internal code gurus will now immediately argue how this is exactly how git's index works internally. Guess what? As a git user, this is not a single bit of how the index concept is visible to the user. As a git user, the index has something to do with already but not yet, or with not only in the working copy but also already somewhere else, or with not yet in a commit but somewhat half- way there. All those points could maybe be captured in some other wording, but for sure neither in the English index nor (and even less) in a German Index. Hence, if the word isn't part of a command name, the translators are free to decide which word to use, and you could probably choose some word that is actually helpful in the target language. Index is not. In case you belong to the 0.5% of version control users who are experienced enough with git to know and understand the English term index, feel free to stick with that word. But in case you target this translation to the somewhat majority of version control users, I suggest you better think again. Thanks for reading. Best Regards, Christian PS: Just for the record: If I explain git to new users and we reach the index concept, my explanation routinely says This concept is called 'index' but it has nothing to do with any associations you make with that word. Better remember this thingy as *** and replace the termin 'index' with *** every time you read about it. where *** is my preferred translation. The facial expressions of the audience regarding index regularly confirm this approach as the better one. I never encountered anyone who says Oh, but isn't 'index' a much better term for this than what you said... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] l10n: de.po: translate index as Index
Am Montag, 1. Juni 2015, 12:34:31 schrieb Stefan Beller: On Mon, Jun 1, 2015 at 12:26 PM, Christian Stimming stimm...@tuhh.de wrote: index concept, my explanation routinely says This concept is called 'index' but it has nothing to do with any associations you make with that word. Better remember this thingy as *** and replace the termin 'index' with *** every time you read about it. where *** is my preferred translation. The facial expressions of the audience regarding index regularly confirm this approach as the better one. I never encountered anyone who says Oh, but isn't 'index' a much better term for this than what you said... So the *** is cut out here, or do you literally advise to think of a black magic box here? I'd be interested to know your preferred translation, maybe that can be used instead of Staging-Area then? Sorry for being unclear here: I left out the concrete word I use because you might need to come up with your own choice in the command-line git translation. The point of this remark is rather that almost any other term is better than leaving index as a term as-is. The term that I use is only one among probably many possibilities. In case you still want to know my preferred German word, I stick to the translations that are used in git-gui, mostly still proposed by myself in (huh) 2008. http://repo.or.cz/w/git-gui.git/blob/HEAD:/po/glossary/de.po There, index isn't used in the user interface anymore but rather staging area, and that's translated into German as Bereitstellung. In my experience this term works quite well for a German-speaking developer audience, even though the term with its military background is only seldomly used or known. But the word triggers some well-suited associations: partly bereit for the next step, partly Stellung as some extra third place in addition to working copy and repository. But that might very well be a different discussion than what you need to discuss for command line git. Regards, Christian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: English/German terminology, git.git's de.po, and pro-git
Dear translators, Here's the main point in this discussion: The translation is not for us! The translation is for those who don't speak much English and who don't know the English git terminology very well. By definition, this target audience is not present here on this mailing list and in this discussion. Hence, arguments such as I like word x better are rather weak. Instead, stating Word x gives the intended target audience a better picture of what is going on is probably a better argument. Am Montag, 13. Mai 2013, 14:54:51 schrieb Thomas Rast: However, an unfortunate and unsatisfactory situation has developed: Christian Stimming's git-gui de.po uses a Ger translation, and Ralf Thielow built core git's de.po on top of it, so it's also Ger. Meanwhile, and independently, Sven Fuchs and Ralph Haussmann wrote a translation of pro-git (which is also quite mature at this point, having apparently begun in 2009), and as you probably guessed by now, it's G+E. Thanks, Thomas, for spotting the conflicting translations in those excellent book projects vs. the git core and git gui. I think it's rather obvious why the pro-git translators chose the G+E approach for their work: Their goal is to explain the command line usage of git, which means they inevitably have to use the git command names, which happen to be in English (and will surely stay so). Hence, any translation approach will have to deal with the English command names as useful words in the normal translated text. That's probably a constraint that is true for any translation of a command-line tool to stay useful. I noticed with some amusement, though, that even in the pro-git book with the described constraint there are places where a pure Ger translation is almost shining through... Such as in [1]: Jedes Mal, wenn Du committest (d.h. den gegenwärtigen Status deines Projektes als eine Version in Git speicherst)... Can you notice how the translators identified Version as translation for commit (noun) and speichern as translation for commit (verb) :-) ? Of course this is just the explanation and not the actual translation later during the text. However, I take this spot as an example that there exist meaningful pure-Ger translations even for the most important git terminology. In fact, to find useful Ger translations, I wonder how I would talk to someone from the target audience a sentence such as Finde mal den richtigen Commit, also die Version, ... When I find myself saying such an - also das xy - appendix often enough, I take this as an indication that the latter word can just as well be used as the main translation. Back to the original question: I think the book shows quite nicely that for working with the git command line, a G+E translation is more useful as long as the command names also appear unchangedly in the translation. However, everything else that does not appear as a command name can be translated either in G+E or in Ger. The argument can go on to state that someone who is geek enough to use the command line is probably more proficient in English language anyway. Hence, using more English terms in the translation is probably fine as well and a full G+E translation is probably a good approach. The pro-git book has some places where the translated word is not always used consistently (e.g. in [2] Externes Repository vs. Remote Repository), and some G+E suggestions from this mailing list have been translated Ger in the book (they use zusammenführen in [2] and [3] instead of merge with only a few exceptions). It is also a good point to make the pro-git and git core translation consistent, once the approach is decided on. *However*: This argument is completely different when we talk about the GUI tools. The target audience of the git gui etc. are those developers who write great code, but #1 do not know the English language well enough, and #2 are so far away from the geek corner that they use a development workflow purely in GUI tools. The question is: What GUI button labels helps those people the most to get a good picture of what is going on? And in this case I still believe a pure Ger translation is the better choice! I wonder how feedback on this claim can be collected from developers of the target audience. When I started on the git-gui translation, I asked some coworkers that fall into this category for feedback on the wordings, and their response indicated agreement to my approach. What feedback have others here heard from people who fall into described category? At the end of the day that sort of feedback has to be the ground for a decision on the approach in the GUI translation. In the meantime I think a different translation approach between git core and git gui is not a problem at all. For git gui I propose to stick to a Ger translation. For git core and the books that describe the command line interface, a G+E translation is probably a good choice but even in
Re: [PATCH/RFC] l10n: de.po: translate 39 new messages
Am Mittwoch, 17. April 2013, 10:09:29 schrieb Thomas Rast: msgid The bundle contains this ref: msgid_plural The bundle contains these %d refs: -msgstr[0] Das Paket enthält %d Referenz -msgstr[1] Das Paket enthält %d Referenzen +msgstr[0] Das Paket enthält diese Referenz: +msgstr[1] Das Paket enthält diese %d Referenzen: The msgstr[0] must still contain a %d conversion specifier (which will be filled with the number 1) even though the translated sentence wouldn't need the 1 anymore. The previous msgstr[0] was correct; the English singular msgid is not. That made me wonder, too. I've played around a bit with this, and it seems to be OK as long as one of those strings contain at least one format specifier. C printf() only knows about the number and types of arguments from the format string, so *ignoring* arguments is not a problem for correctness. Indeed both of you are correct and I learned something new. http://stackoverflow.com/questions/3578970/passing-too-many-arguments-to- printf where the second answer quotes Online C Draft Standard (n1256), section 7.19.6.1, paragraph 2: If the format is exhausted while arguments remain, the excess arguments are evaluated (as always) but are otherwise ignored. Hence, it is indeed safe to skip unneeded conversion specifiers both in general ngettext messages and also in their respective translation. This is an explanation which has yet to be added to ngettext's documentation. Best Regards, Christian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] l10n: de.po: translate 39 new messages
Thanks for the regular update! This is great work. One issue with the plural form messages, though: Am Montag, 15. April 2013, 18:27:40 schrieb Ralf Thielow: #: bundle.c:186 -#, fuzzy, c-format +#, c-format msgid The bundle contains this ref: msgid_plural The bundle contains these %d refs: -msgstr[0] Das Paket enthält %d Referenz -msgstr[1] Das Paket enthält %d Referenzen +msgstr[0] Das Paket enthält diese Referenz: +msgstr[1] Das Paket enthält diese %d Referenzen: The msgstr[0] must still contain a %d conversion specifier (which will be filled with the number 1) even though the translated sentence wouldn't need the 1 anymore. The previous msgstr[0] was correct; the English singular msgid is not. Technical background: The ngettext function chooses only the string itself, which will then be fed to printf() as a second step. If the printf sees more variadic arguments than conversion specifiers in the string, it will be unhappy. At least that's what I remembered about the ngettext things... http://www.gnu.org/software/libc/manual/html_node/Advanced-gettext- functions.html Regards, Christian -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
