{"thread":{"id":"27618","subject":"Using Transifex in git.git","startedAt":"2011-06-14T05:57:20Z","lastAt":"2011-06-15T20:58:09Z","messageCount":14,"participants":["Ramkumar Ramachandra","Andreas Ericsson","Ævar Arnfjörð Bjarmason","Erik Faye-Lund","Michael Witten"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"169979","messageId":"BANLkTikQJYYd4sTJoDrL28Bo35+GpV3HgA@mail.gmail.com","threadId":"27618","inReplyTo":null,"subject":"Using Transifex in git.git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-14T05:57:20Z","receivedAt":"2011-06-14T05:57:20Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Dimitris et al,\n\n[+CC: Git List; for wider exposure]\n[+CC: Jonathan Nieder; he has been involved with translations in the past]\n[+CC: Junio C Hamano; for authoritative policy advice]\n\nI think it's a good idea to use a system like Transifex to manage\ntranslations for git.git, so that we can attract a large number of\nnon-technical translators. Further, I think it's a good time to start\noff on this now, since many of the i18n bits from Ævar's series are in\n'master'. So, I'm looking to start off a discussion about how to\nadapt a translation system into our current patch workflow. Dimitris\nis the lead developer of Transifex, and can help with the details.\n\nThanks.\n\n-- Ram\n"},{"id":"169986","messageId":"4DF726F4.3000204@op5.se","threadId":"27618","inReplyTo":"BANLkTikQJYYd4sTJoDrL28Bo35+GpV3HgA@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-06-14T09:16:36Z","receivedAt":"2011-06-14T09:16:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 06/14/2011 07:57 AM, Ramkumar Ramachandra wrote:\n> Hi Dimitris et al,\n> \n> [+CC: Git List; for wider exposure]\n> [+CC: Jonathan Nieder; he has been involved with translations in the past]\n> [+CC: Junio C Hamano; for authoritative policy advice]\n> \n> I think it's a good idea to use a system like Transifex to manage\n> translations for git.git, so that we can attract a large number of\n> non-technical translators. Further, I think it's a good time to start\n> off on this now, since many of the i18n bits from Ævar's series are in\n> 'master'. So, I'm looking to start off a discussion about how to\n> adapt a translation system into our current patch workflow. Dimitris\n> is the lead developer of Transifex, and can help with the details.\n> \n\nIt's always better to start coding on changes and then show how those\nchanges make life easier for people than to suggest something out of\nthin air and start a discussion about it before applying any work.\n\nI for one have no idea what transifex is, how it works or why it's\nsuperior to any of the currently existing tools to manage .po files.\nI also have no real interest in translations, although I chip in a\nbit with the swedish one when someone else does the grunt part of the\nwork to make it happen. I believe many here share that sentiment with\nme, so you'd probably be better off doing a sales-pitch kind of mail\nto the people who have contributed greatly to the actual translations\nearlier so they can voice their opinions on what system they want to\nuse.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"169987","messageId":"BANLkTikLJJwfGJp_nshRXGSb-yGOshwzTg@mail.gmail.com","threadId":"27618","inReplyTo":"BANLkTikQJYYd4sTJoDrL28Bo35+GpV3HgA@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-06-14T09:37:13Z","receivedAt":"2011-06-14T09:37:13Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Jun 14, 2011 at 07:57, Ramkumar Ramachandra wrote:\n> Hi Dimitris et al,\n>\n> [+CC: Git List; for wider exposure]\n> [+CC: Jonathan Nieder; he has been involved with translations in the past]\n> [+CC: Junio C Hamano; for authoritative policy advice]\n>\n> I think it's a good idea to use a system like Transifex to manage\n> translations for git.git, so that we can attract a large number of\n> non-technical translators.  Further, I think it's a good time to start\n> off on this now, since many of the i18n bits from Ævar's series are in\n> 'master'.  So, I'm looking to start off a discussion about how to\n> adapt a translation system into our current patch workflow.  Dimitris\n> is the lead developer of Transifex, and can help with the details.\n\nTurns out I have two E-Mails related to this in my inbox. Below\nfollows the reply I sent to the other one in private mail, but applies\nhere too:\n\n\"\"\"\nSorry, I didn't have time to look at this at the time. I think it's\nreally interesting, having translations be easier to manage is\ndefinitely something we want so that mortals can contribute\ntranslations to git.\n\nI hadn't followed up on this because git.git still doesn't have\nstrings marked up for translation. We have the C bits of that, but the\npatch series for the shellscripts is still in flight.\n\nAfter that I was going to submit some more patches to add the initial\npo/*.po files, after which I think considering having a web interface\nlike this would make sense.\n\nHere's a couple of things though:\n\n * I don't want people to *have* to use any one interface.\n\n As far as I'm concerned the canonical way to submit translations is\n just to check out git.git's master branch, run \"make pot\", and then\n submit a patch for a PO file to the list.\n\n Of course we can *also* support doing that through a web UI, the web\n UI is after all just a fancy way of replacing your $EDITOR. But I\n don't think we should be tied to any one UI. I.e. people should be\n able to take git.pot and edit it everywhere, and a web UI like\n Transifex can't assume that it e.g. won't have to resolve conflicts\n because something changed upstream.\n\n * Any way of editing the translations will have to comply with git's\n normal patch submission process.\n\n When you normally submit a patch to Git you have to write a\n sensible commit message for it, change one logical thing at a time,\n and you have to agree to the contributor's agreement by adding a\n Signed-off-by to your Git commit.\n\n I think this will probably clash head-on with how any web\n translation UI with its own user accounts, no way to enter commit\n messages etc. will work.\n\"\"\"\n"},{"id":"169990","messageId":"BANLkTinkc6yZ39JVtBaENikFj5xPKnh9mw@mail.gmail.com","threadId":"27618","inReplyTo":"4DF726F4.3000204@op5.se","subject":"Re: Using Transifex in git.git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-14T10:12:12Z","receivedAt":"2011-06-14T10:12:12Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Andreas,\n\nAndreas Ericsson writes:\n> It's always better to start coding on changes and then show how those\n> changes make life easier for people than to suggest something out of\n> thin air and start a discussion about it before applying any work.\n\nYes, this would normally be the case. My apologies for being unclear\nabout the purpose of the original email: It's not a sales pitch where\nI'm trying to sell one translation system - I'm merely trying to find\nout what features the community at large would like from an abstract\nweb-based translation engine; what should it look like so that it fits\ninto our current patch/ review system? What this translates to in\nterms of work: evaluation various translation systems, and writing the\nnecessary features into the one that comes closest to what we want.\nAt a glance, Transifex seems to be a good option, but I could easily\nbe wrong about that.\n\n-- Ram\n"},{"id":"169994","messageId":"BANLkTimXLUG-MZC3AndkequF3wVNwqDOeQ@mail.gmail.com","threadId":"27618","inReplyTo":"BANLkTikLJJwfGJp_nshRXGSb-yGOshwzTg@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-14T11:02:16Z","receivedAt":"2011-06-14T11:02:16Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Ævar,\n\nÆvar Arnfjörð Bjarmason writes:\n>  * I don't want people to *have* to use any one interface.\n>  * Any way of editing the translations will have to comply with git's\n>  normal patch submission process.\n\nThanks for the detailed response. The way I see it, major changes are\nrequired in two distinct areas:\n1. The way the user interacts with the web-based UI. In the current\nUI (of Transifex), everything is one continuous stream; everything is\nauto-saved, and the user makes no indication of a logical change.\nThis has to be changed to enforce creation of commit messages for the\nGit project: without a valid commit message and signoff, the\ntranslations are essentially useless. Also, authorship information\nisn't available -- so, the user accounts should have a way to keep\nthis information, and the Git project should be able to demand that\nthis information is available.\n2. The way the system stores the various versions of the translation\ninformation, and gives it back to the individual projects. Some\nprojects might like the continuous stream to be squashed into one\ncommit that says something like \"Sync translations with Transifex\"\nlike it does current, some might like a Subversion dumpstream, while\nothers like the Git project might like a fast-import stream. When we\nget the stream, we should be able to import it, rebase the commits as\nnecessary, and throw away the commits that we don't like before\nintegrating it.\n\nI'll start mocking up a solution. Are there some issues that I\nhaven't covered yet?\n\n-- Ram\n"},{"id":"169996","messageId":"4DF74EEC.1050506@op5.se","threadId":"27618","inReplyTo":"BANLkTikLJJwfGJp_nshRXGSb-yGOshwzTg@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-06-14T12:07:08Z","receivedAt":"2011-06-14T12:07:08Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 06/14/2011 11:37 AM, Ævar Arnfjörð Bjarmason wrote:\n> On Tue, Jun 14, 2011 at 07:57, Ramkumar Ramachandra wrote:\n>> Hi Dimitris et al,\n>>\n>> [+CC: Git List; for wider exposure]\n>> [+CC: Jonathan Nieder; he has been involved with translations in the past]\n>> [+CC: Junio C Hamano; for authoritative policy advice]\n>>\n>> I think it's a good idea to use a system like Transifex to manage\n>> translations for git.git, so that we can attract a large number of\n>> non-technical translators. Further, I think it's a good time to start\n>> off on this now, since many of the i18n bits from Ævar's series are in\n>> 'master'. So, I'm looking to start off a discussion about how to\n>> adapt a translation system into our current patch workflow. Dimitris\n>> is the lead developer of Transifex, and can help with the details.\n> \n> Turns out I have two E-Mails related to this in my inbox. Below\n> follows the reply I sent to the other one in private mail, but applies\n> here too:\n> \n> * Any way of editing the translations will have to comply with git's\n> normal patch submission process.\n> \n> When you normally submit a patch to Git you have to write a\n> sensible commit message for it, change one logical thing at a time,\n> and you have to agree to the contributor's agreement by adding a\n> Signed-off-by to your Git commit.\n> \n\nHistorically, a translation for one language has been considered \"one\nlogical change\" in that respect. I think it's safe to assume that if\nwe want translators to stick around they shouldn't need to divide their\nchanges on a per-message or per-command basis. Especially since such\ndivisions wouldn't be very easy to do if all you've got to go on is\na pot-file.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"170043","messageId":"BANLkTikCB7t4DhCxjLT-JABsUuksPBhkLw@mail.gmail.com","threadId":"27618","inReplyTo":"4DF74EEC.1050506@op5.se","subject":"Re: Using Transifex in git.git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-15T07:33:42Z","receivedAt":"2011-06-15T07:33:42Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Andreas,\n\nAndreas Ericsson writes:\n> Historically, a translation for one language has been considered \"one\n> logical change\" in that respect. I think it's safe to assume that if\n> we want translators to stick around they shouldn't need to divide their\n> changes on a per-message or per-command basis. Especially since such\n> divisions wouldn't be very easy to do if all you've got to go on is\n> a pot-file.\n\nFair point. How do we work around this?\n1. Can we relax the requirements for contributing translations? To what extent?\n2. It think one commit per edit-session per language sounds sane. If\npeople just go around translating some random strings that they like\n(which is often the case), what is the sense in asking them to write a\ncommit message? Maybe we can write one ourselves before committing it,\nprovided they signoff on all the commits? Maybe there should be an\nauto-signoff option too?\n\n-- Ram\n"},{"id":"170044","messageId":"4DF86BB3.4070906@op5.se","threadId":"27618","inReplyTo":"BANLkTikCB7t4DhCxjLT-JABsUuksPBhkLw@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-06-15T08:22:11Z","receivedAt":"2011-06-15T08:22:11Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 06/15/2011 09:33 AM, Ramkumar Ramachandra wrote:\n> Hi Andreas,\n> \n> Andreas Ericsson writes:\n>> Historically, a translation for one language has been considered \"one\n>> logical change\" in that respect. I think it's safe to assume that if\n>> we want translators to stick around they shouldn't need to divide their\n>> changes on a per-message or per-command basis. Especially since such\n>> divisions wouldn't be very easy to do if all you've got to go on is\n>> a pot-file.\n> \n> Fair point. How do we work around this?\n> 1. Can we relax the requirements for contributing translations? To what extent?\n\nProbably at least a bit. It doesn't affect core functionality in any\nway so it's unlikely it will cause bugs that requires deep diving in\nthe history, so changes needn't be so isolated and commit messages\nare less important than for code changes.\n\n> 2. It think one commit per edit-session per language sounds sane.\n\nYup.\n\n> If\n> people just go around translating some random strings that they like\n> (which is often the case), what is the sense in asking them to write a\n> commit message? Maybe we can write one ourselves before committing it,\n> provided they signoff on all the commits? Maybe there should be an\n> auto-signoff option too?\n> \n\nNo and no. No auto-signoff, and no auto-message. That will just leave\nus with a long string of auto-signoffs and automatic messages, and\nthat's horrible.\n\nThe \"no auto-signoff\" rule is from Junio btw, and I doubt he's changed\nhis mind regarding that. The \"no auto-message\" is just my gut feeling\nthat everyone will really hate to see changes without an explanation.\nSomething simple like \"5 out of 6 of the large scm's (in terms of\nuserbase) uses 'blarg' instead of 'fnurg' for commits, so let's call\nit that in our examplinitian translation too\" is enough and will be\nquite helpful when it comes to explaining why a change is made.\n\nOtoh, \"Updated translations for new release\" will probably be the\nmost common message, and that's fine too if that's what happened.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"170052","messageId":"BANLkTin5mJ4WsAd6eRUUoJykxRu+vJ-_oQ@mail.gmail.com","threadId":"27618","inReplyTo":"4DF86BB3.4070906@op5.se","subject":"Re: Using Transifex in git.git","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-06-15T10:10:41Z","receivedAt":"2011-06-15T10:10:41Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi again,\n\nAndreas Ericsson writes:\n> No and no. No auto-signoff, and no auto-message. That will just leave\n> us with a long string of auto-signoffs and automatic messages, and\n> that's horrible.\n>\n> The \"no auto-signoff\" rule is from Junio btw, and I doubt he's changed\n> his mind regarding that. The \"no auto-message\" is just my gut feeling\n> that everyone will really hate to see changes without an explanation.\n> Something simple like \"5 out of 6 of the large scm's (in terms of\n> userbase) uses 'blarg' instead of 'fnurg' for commits, so let's call\n> it that in our examplinitian translation too\" is enough and will be\n> quite helpful when it comes to explaining why a change is made.\n>\n> Otoh, \"Updated translations for new release\" will probably be the\n> most common message, and that's fine too if that's what happened.\n\n1. Auto signoffs: Do you want translators to explicitly type out s-o-b\nmessage after contributing a few translations?! I think it's fair to\nassume that many of us use auto-signoffs as well -- I personally have\nformat.signoff set to true, but I've read SubmittingPatches. I don't\npropose to have a blind auto signoff, but translators can atleast be\nforced to read the agreement and hit \"Yes, I want to auto signoff all\nmy contributions\".\n2. Auto commit messages: Er, what I meant: the translation coordinator\nhas to clean up the history and fill in the commit messages before she\ntries to get the new translations merged into git.git. The lazy\ntranslators have the option of leaving it empty.\n\nOne quick query: Let's say there are 10 tiny commits modifying the\nsame line in the same language, and the translation coordinator wants\nto squash these into one. Is it alright to have the authorship info\npoint to the coordinator, with the commit message crediting all 10\nindividual translators?\n\n-- Ram\n"},{"id":"170062","messageId":"BANLkTin9bhtB_OPMWCVsbtKBpRXp2o=uLA@mail.gmail.com","threadId":"27618","inReplyTo":"BANLkTikQJYYd4sTJoDrL28Bo35+GpV3HgA@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-06-15T13:21:49Z","receivedAt":"2011-06-15T13:21:49Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra\n wrote:\n> I think it's a good idea to use a system like Transifex to manage\n> translations for git.git, so that we can attract a large number of\n> non-technical translators.\n\nAre we sure we want non-technical translators to translate Git, a\nhighly technical program with many technical terms?\n\nI'm guessing that Git probably should be translated by it's users,\nbecause we have a lot of Git-jargon that is difficult for people who\ndoesn't know Git to translate. But perhaps an initial translation for\neach language is enough to establish a language-specific translation\nof all Git-jargon, and then afterwards we can get help from\nnon-technical people to improve the language? I'm just asking, I don't\nknow how Transifex works at all...\n"},{"id":"170063","messageId":"BANLkTikkOMmp869q8x4c8PPe1AGKP4+Qfw@mail.gmail.com","threadId":"27618","inReplyTo":"BANLkTin9bhtB_OPMWCVsbtKBpRXp2o=uLA@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Michael Witten","fromEmail":"mfwitten@gmail.com","sentAt":"2011-06-15T13:45:57Z","receivedAt":"2011-06-15T13:45:57Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On Wed, Jun 15, 2011 at 13:21, Erik Faye-Lund wrote:\n> On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra\n> wrote:\n>> I think it's a good idea to use a system like Transifex to manage\n>> translations for git.git, so that we can attract a large number of\n>> non-technical translators.\n>\n> Are we sure we want non-technical translators to translate Git, a\n> highly technical program with many technical terms?\n>\n> I'm guessing that Git probably should be translated by it's users,\n> because we have a lot of Git-jargon that is difficult for people who\n> doesn't know Git to translate. But perhaps an initial translation for\n> each language is enough to establish a language-specific translation\n> of all Git-jargon, and then afterwards we can get help from\n> non-technical people to improve the language? I'm just asking, I don't\n> know how Transifex works at all...\n\nI think your second paragraph ALMOST has the right of it.\n\nOpen source showed us the virtue of \"Release early and release often\";\nit's best to get people using something even if it's crap at first,\nespecially because people can then figure out what needs to be\nbettered.\n\nWikipedia showed us that if we reduce the requirements to contribution\n(which, if you think about it, also means that backwards compatibility\nmust be largely forgone), then the net result is a constantly and\nrapidly improving product (albeit with minor but inconsequential\nsetbacks due to fools and miscreants).\n\nSo, who cares if the translation for the Nǁngǃke language (look it up)\nis initially junk at first; if it's easy to fix, then it will rapidly\nimprove into a steady state of high quality.\n"},{"id":"170081","messageId":"BANLkTin6SPDb8r1fjwWHVmh215esRo5+0Q@mail.gmail.com","threadId":"27618","inReplyTo":"4DF74EEC.1050506@op5.se","subject":"Re: Using Transifex in git.git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-06-15T20:40:03Z","receivedAt":"2011-06-15T20:40:03Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Jun 14, 2011 at 14:07, Andreas Ericsson wrote:\n\n> Historically, a translation for one language has been considered \"one\n> logical change\" in that respect. I think it's safe to assume that if\n> we want translators to stick around they shouldn't need to divide their\n> changes on a per-message or per-command basis. Especially since such\n> divisions wouldn't be very easy to do if all you've got to go on is\n> a pot-file.\n\nThen again, our policy with patches to the C code is that you should\nmake make changes in small logical chunks with good commit messages,\nso that the people that come after you can make sense of what you did.\n\nTranslations are similar, why you chose to translate certain terms in\ncertain ways could (and IMO should) be explained in commit messages.\n\nI don't think it should be a per-command or per-message basis, just\nsomething like:\n\n * commit 1: start a XX.po file\n * commit 2: translate the word \"branch\", and explain why you picked\n that particular translation.\n * Translate similar messages etc.\n\nOr do the whole thing in one big commit, but have a commit message\nthat explains the choice of translations.\n"},{"id":"170082","messageId":"BANLkTik7Kb6ae0aRNjL3RcMouhw2gkOwPA@mail.gmail.com","threadId":"27618","inReplyTo":"BANLkTin9bhtB_OPMWCVsbtKBpRXp2o=uLA@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-06-15T20:43:53Z","receivedAt":"2011-06-15T20:43:53Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Jun 15, 2011 at 15:21, Erik Faye-Lund wrote:\n> On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra\n> wrote:\n>> I think it's a good idea to use a system like Transifex to manage\n>> translations for git.git, so that we can attract a large number of\n>> non-technical translators.\n>\n> Are we sure we want non-technical translators to translate Git, a\n> highly technical program with many technical terms?\n\nWell, usually even bad translations (although not horribly bad) are\nbetter than nothing.\n\nMost translated strings will have little or nothing git-specific about\nthem, but will be something like \"We couldn't open file %s due to\nXYZ\".\n\nAnd even if someone translates e.g. \"branch\" incorrectly they usually\ndo so consistently, so it's easy to search & replace those sort of\nissues out of existence.\n"},{"id":"170084","messageId":"BANLkTimSKGdRKCOzVWZ3gmX_xBUwHoDuaw@mail.gmail.com","threadId":"27618","inReplyTo":"BANLkTikLJJwfGJp_nshRXGSb-yGOshwzTg@mail.gmail.com","subject":"Re: Using Transifex in git.git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-06-15T20:58:09Z","receivedAt":"2011-06-15T20:58:09Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Jun 14, 2011 at 11:37, Ævar Arnfjörð Bjarmason wrote:\n\nTo clarify a bit. I think it'd be great if we can get more\ntranslations through any scheme possible.\n\nHowever, I'd personally prefer if this was delayed a bit until the\noutstanding po/*.po patches I have have landed in master. I already\nhave those locally ready for submission, I'm just going to submit them\nafter my current series hits master.\n\nThe timeline on that is entirely dependent on when Junio merges my\npatches down.\n\nBut that's just my 0.02c. I don't think I own i18n in any way, so if\nsomeone wants to set up some web ui, gather PO files, and submit them\nthat's great. More power to them.\n\n>  * Any way of editing the translations will have to comply with git's\n>  normal patch submission process.\n\nAlso, I just mentioned this because those are our existing patch\nsubmission guidelines, which I thought would be reasonable to assume\nwould be the same in this case. Whether we observe this I think would\nbe something for the maintainer to answer.\n\nPersonally I think signed-off-by is silly, and wouldn't mind if we got\nnew translations in one giant commit with a crappy commit message, but\nI didn't make the rules.\n"}]}