{"thread":{"id":"24643","subject":"Cooking of the ab/i18n series","startedAt":"2010-08-05T21:09:52Z","lastAt":"2010-08-07T01:13:47Z","messageCount":10,"participants":["Ævar Arnfjörð Bjarmason","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"147250","messageId":"AANLkTi=bnDgUsnBCv5493sH9eY5hg0S2YPywKba9jD20@mail.gmail.com","threadId":"24643","inReplyTo":null,"subject":"Cooking of the ab/i18n series","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-05T21:09:52Z","receivedAt":"2010-08-05T21:09:52Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Aug 4, 2010 at 22:24, Junio C Hamano wrote:\n\nSince we're asking about the status of series...\n\n> * tr/ab-i18n-fix (2010-07-25) 1 commit\n>  - tests: locate i18n lib&data correctly under --valgrind\n>  (this branch uses ab/i18n.)\n\n> * ab/i18n (2010-07-19) 2 commits\n>  - tests: rename test to work around GNU gettext bug\n>  - Add infrastructure for translating Git with gettext\n>  (this branch is used by tr/ab-i18n-fix.)\n\nDo you have any plans for when to merge the i18n series?\n\nIt's been cooking for a while now, and it'll need a lot of follow-up\nwork (gettextizing) once it gets merged.\n\nI don't have infinite time to do that, so sooner rather than later\nwould be better if we're going to e.g. have a fully localized Git 1.8.\n\nI haven't been sending these follow up patches due to the reasons I\nalready cited. They're pretty much guaranteed to conflict with other\nthings in-flight.\n\nIf you're not comfortable with merging it soon for whatever reason\nthen perhaps I could submit something to add a no-op N_() macro to Git\nin the interim. Then we could just do s/N_/_/ on the source tree once\nthe real series gets merged.\n"},{"id":"147262","messageId":"7vzkx0bt4w.fsf@alter.siamese.dyndns.org","threadId":"24643","inReplyTo":"AANLkTi=bnDgUsnBCv5493sH9eY5hg0S2YPywKba9jD20@mail.gmail.com","subject":"Re: Cooking of the ab/i18n series","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-05T22:18:39Z","receivedAt":"2010-08-05T22:18:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Wed, Aug 4, 2010 at 22:24, Junio C Hamano wrote:\n>\n> Since we're asking about the status of series...\n>\n>> * tr/ab-i18n-fix (2010-07-25) 1 commit\n>>  - tests: locate i18n lib&data correctly under --valgrind\n>>  (this branch uses ab/i18n.)\n>\n>> * ab/i18n (2010-07-19) 2 commits\n>>  - tests: rename test to work around GNU gettext bug\n>>  - Add infrastructure for translating Git with gettext\n>>  (this branch is used by tr/ab-i18n-fix.)\n>\n> Do you have any plans for when to merge the i18n series?\n\nWhen people see the benefit of doing so. I currently do not see much need\nfor it myself but I am a minority ;-).\n\n> It's been cooking for a while now, and it'll need a lot of follow-up\n> work (gettextizing) once it gets merged.\n\nYeah, and s/once/before/ probably.\n"},{"id":"147309","messageId":"AANLkTim1G=wjAgts_BvjwU8_B1wqrUEQHWbP_MY=cJa9@mail.gmail.com","threadId":"24643","inReplyTo":"7vzkx0bt4w.fsf@alter.siamese.dyndns.org","subject":"Re: Cooking of the ab/i18n series","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-06T12:33:10Z","receivedAt":"2010-08-06T12:33:10Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Aug 5, 2010 at 22:18, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Wed, Aug 4, 2010 at 22:24, Junio C Hamano wrote:\n>>\n>> Since we're asking about the status of series...\n>>\n>>> * tr/ab-i18n-fix (2010-07-25) 1 commit\n>>>  - tests: locate i18n lib&data correctly under --valgrind\n>>>  (this branch uses ab/i18n.)\n>>\n>>> * ab/i18n (2010-07-19) 2 commits\n>>>  - tests: rename test to work around GNU gettext bug\n>>>  - Add infrastructure for translating Git with gettext\n>>>  (this branch is used by tr/ab-i18n-fix.)\n>>\n>> Do you have any plans for when to merge the i18n series?\n>\n> When people see the benefit of doing so.  I currently do not see much need\n> for it myself but I am a minority ;-).\n\nThat's news to me. I'd assumed that it was mostly on track, i.e. that\nit would get merged down after cooking for a while in pu.\n\nHowever, if it's a matter of gathering popular support maybe I should\nchange my strategy a bit.\n\nPerhaps it would help if I sent the entire series as it is in pu now\nto the list along with a cover letter explaining the main implications\nof merging it?\n\nAll the RFCs so far have either focused on discussing the idea without\nthe implementation, or small parts of the implementation that needed\nto be improved.\n\n>> It's been cooking for a while now, and it'll need a lot of follow-up\n>> work (gettextizing) once it gets merged.\n>\n> Yeah, and s/once/before/ probably.\n\nWhat sort of work do you think is needed before it's merged? It seems\nto Just Work everywhere I and others have tested it (sans some minor\npatches like working around old gettext bugs).\n\nThe follow-up work I was referring to was the project we'll need to\nundertake once it's merged to convert \"foo\" to _(\"foo\") as\nappropriate.\n\nWhat sort of work do you think might be needed before it's merged?\n"},{"id":"147311","messageId":"7vmxszamwd.fsf@alter.siamese.dyndns.org","threadId":"24643","inReplyTo":"AANLkTim1G=wjAgts_BvjwU8_B1wqrUEQHWbP_MY=cJa9@mail.gmail.com","subject":"Re: Cooking of the ab/i18n series","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-06T13:30:58Z","receivedAt":"2010-08-06T13:30:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Thu, Aug 5, 2010 at 22:18, Junio C Hamano wrote:\n>>\n>> When people see the benefit of doing so.  I currently do not see much need\n>> for it myself but I am a minority ;-).\n>\n> That's news to me. I'd assumed that it was mostly on track, i.e. that\n> it would get merged down after cooking for a while in pu.\n>\n> However, if it's a matter of gathering popular support maybe I should\n> change my strategy a bit.\n\nThe \"popular support\" needs to be qualified. If you ask any random person\n\"Is it a good thing if software package X supports i18n?\", the answer\nwould always be \"yes\"; popular support in that sense doesn't mean much.\n\nI am more worried about unintended consequence of this particular\nexecution. For example, I would want to be absolutely sure that we won't\nbreak plumbing output in 'next' and the proposed mechanism helps others\navoid breaking things by mistake.\n\n> The follow-up work I was referring to was the project we'll need to\n> undertake once it's merged to convert \"foo\" to _(\"foo\") as\n> appropriate.\n\nThat is one good example. Perhaps we can get a list of messages that we\ncan place in Documentation/ area (e.g. \"'Not up-to-date' - this message is\ngiven when you have local changes in a file in the working tree; given by\ncommand X, Y and Z\") out of that effort for free? Perhaps such a list can\nhelp us verify that i18n does not break plumbing output (because the list\ndoes not contain plumbing messages)?\n"},{"id":"147317","messageId":"AANLkTimooDYBW3N0qV4G2JKSvcdWiCVRj3WjuoO+CJ54@mail.gmail.com","threadId":"24643","inReplyTo":"7vmxszamwd.fsf@alter.siamese.dyndns.org","subject":"Re: Cooking of the ab/i18n series","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-06T14:03:54Z","receivedAt":"2010-08-06T14:03:54Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Aug 6, 2010 at 13:30, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Thu, Aug 5, 2010 at 22:18, Junio C Hamano wrote:\n>>>\n>>> When people see the benefit of doing so.  I currently do not see much need\n>>> for it myself but I am a minority ;-).\n>>\n>> That's news to me. I'd assumed that it was mostly on track, i.e. that\n>> it would get merged down after cooking for a while in pu.\n>>\n>> However, if it's a matter of gathering popular support maybe I should\n>> change my strategy a bit.\n>\n> The \"popular support\" needs to be qualified.  If you ask any random person\n> \"Is it a good thing if software package X supports i18n?\", the answer\n> would always be \"yes\"; popular support in that sense doesn't mean much.\n\nI was thinking about support from the core contributors, which'd have\nto deal with gettext in the long term in one way or another.\n\n> I am more worried about unintended consequence of this particular\n> execution.  For example, I would want to be absolutely sure that we won't\n> break plumbing output in 'next' and the proposed mechanism helps others\n> avoid breaking things by mistake.\n\nI'm also worried about that, and I have some plans to deal with it\nafter the merge.\n\nThe first and most obvious one is that the list will be reviewing\ngettexizing patches as they go through. A patch which changes some\nplumbing format would be called out, but not one that just changes the\nUI messsage of e.g. \"git init\".\n\nThere's also more that can be done, e.g. altering the test-lib.sh so\nthat you can set an environment variable that causes it not to reset\nLC_ALL to C. Then run the tests and see if anything breaks.\n\nI was going to run a smoker with that setup on some of the major\nlanguages if gettext and smoke support was accepted.\n\n>> The follow-up work I was referring to was the project we'll need to\n>> undertake once it's merged to convert \"foo\" to _(\"foo\") as\n>> appropriate.\n>\n> That is one good example.  Perhaps we can get a list of messages that we\n> can place in Documentation/ area (e.g. \"'Not up-to-date' - this message is\n> given when you have local changes in a file in the working tree; given by\n> command X, Y and Z\") out of that effort for free?  Perhaps such a list can\n> help us verify that i18n does not break plumbing output (because the list\n> does not contain plumbing messages)?\n\nWe'd get this sort of list out of \"TRANSLATORS:\" comments for\nfree. They're automatically extracted and presented to translators and\nothers with the xgettext program.\n\nMaintaining a list of messages in Documentation/ somewhere that's\nbound to get out of date with the source code doesn't make sense given\nthe TRANSLATORS support.\n"},{"id":"147323","messageId":"7viq3nagje.fsf@alter.siamese.dyndns.org","threadId":"24643","inReplyTo":"AANLkTimooDYBW3N0qV4G2JKSvcdWiCVRj3WjuoO+CJ54@mail.gmail.com","subject":"Re: Cooking of the ab/i18n series","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-06T15:48:21Z","receivedAt":"2010-08-06T15:48:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> On Fri, Aug 6, 2010 at 13:30, Junio C Hamano wrote:\n>> That is one good example.  Perhaps we can get a list of messages that we\n>> can place in Documentation/ area (e.g. \"'Not up-to-date' - this message is\n>> given when you have local changes in a file in the working tree; given by\n>> command X, Y and Z\") out of that effort for free?  Perhaps such a list can\n>> help us verify that i18n does not break plumbing output (because the list\n>> does not contain plumbing messages)?\n>\n> We'd get this sort of list out of \"TRANSLATORS:\" comments for\n> free. They're automatically extracted and presented to translators and\n> others with the xgettext program.\n>\n> Maintaining a list of messages in Documentation/ somewhere that's\n> bound to get out of date with the source code doesn't make sense given\n> the TRANSLATORS support.\n\nRead it again---I didn't say \"maintaining\" a list at all; we are saying\nthe same thing more or less ;-) You might need to massage the output from\nTRANSLATORS: comment to a more readable form suitable for inclusion in the\ndocumentation (depending on how that thing looks like), though.\n"},{"id":"147328","messageId":"AANLkTimJCgZ8kU0Nrm6Zi-PXSgT96bFfTi0oaaX2t-6v@mail.gmail.com","threadId":"24643","inReplyTo":"7viq3nagje.fsf@alter.siamese.dyndns.org","subject":"Re: Cooking of the ab/i18n series","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-06T17:01:19Z","receivedAt":"2010-08-06T17:01:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Aug 6, 2010 at 15:48, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> On Fri, Aug 6, 2010 at 13:30, Junio C Hamano wrote:\n>>> That is one good example.  Perhaps we can get a list of messages that we\n>>> can place in Documentation/ area (e.g. \"'Not up-to-date' - this message is\n>>> given when you have local changes in a file in the working tree; given by\n>>> command X, Y and Z\") out of that effort for free?  Perhaps such a list can\n>>> help us verify that i18n does not break plumbing output (because the list\n>>> does not contain plumbing messages)?\n>>\n>> We'd get this sort of list out of \"TRANSLATORS:\" comments for\n>> free. They're automatically extracted and presented to translators and\n>> others with the xgettext program.\n>>\n>> Maintaining a list of messages in Documentation/ somewhere that's\n>> bound to get out of date with the source code doesn't make sense given\n>> the TRANSLATORS support.\n>\n> Read it again---I didn't say \"maintaining\" a list at all; we are saying\n> the same thing more or less ;-)  You might need to massage the output from\n> TRANSLATORS: comment to a more readable form suitable for inclusion in the\n> documentation (depending on how that thing looks like), though.\n\nAh yes. I didn't read it carefully enough. Yeah, if we're just talking\nabout autogeneration it isn't hard to get a list of all translatable\nstrings into a single ASCIIDOC page.\n\nI plan to write some translator documentation once this gets in and we\nstart having people submit translations. E.g. a document that lists\nsome of the core Git concepts that the translator will need to\ntranslate (e.g. \"pull\", \"push\", \"commit\", \"tree\", \"object\" etc.).\n"},{"id":"147335","messageId":"AANLkTik1KVpb25nuwSFA2z4ezRJKWdTwRrS_KXzwM+2D@mail.gmail.com","threadId":"24643","inReplyTo":"AANLkTimJCgZ8kU0Nrm6Zi-PXSgT96bFfTi0oaaX2t-6v@mail.gmail.com","subject":"Re: Cooking of the ab/i18n series","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-06T19:28:19Z","receivedAt":"2010-08-06T19:28:19Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Aug 6, 2010 at 17:01, Ævar Arnfjörð Bjarmason wrote:\n> On Fri, Aug 6, 2010 at 15:48, Junio C Hamano wrote:\n> [...]\n\nI don't mean to bombard you with E-Mails, but hopefully this one is a\nbit more to the point.\n\nAs I'm sure you've gathered by now I'm keen to get this into Git. I'm\nalso fully prepared to address any specific concerns about the series\nbefore it gets merged.\n\nHowever, and maybe I'm just dense, I can't really see some unambiguous\nthings about the series that I could improve from your comments. So\nlet's try to clear them up, shall we?\n\nMy mental plan for this series has basically been as follows:\n\n 1. Get it to a state where it can cook in pu [You Are Here]\n\n 2. After it's been there for a while get it to master\n\n 3. Once it's there for a while and we're sure the new dependency /\n code doesn't harm some more obscure systems..\n\n 4. Start submitting patches to the main porcelain $(grep\n 'mainporcelain common' command-list.txt) to make the most common\n user-visible messages translatable.\n\n 5. Recruit translators to translate the strings in #4. Send\n translations in as patches adding/altering the *.po files.\n\nWhile doing #4 and #5 I planned to write some new\ndocumentation. E.g. a quick guide for Git hackers showing how you can\nadd strings that are properly i18n-able. And for #5 an equivalent\nthing for non-techie translators showing what the need to translate,\nhow to submit translations etc.\n\nNow, your main concern is that this doesn't break plumbing output. My\nplan for that was to just leave it for later. As long as I'm not\naltering something in 'mainporcelain common' I'm not going to break\nthe plumbing.\n\nI think I can read between the lines that you're uneasy about this\napproach. But I'm not sure how else to handle it.\n\nOne thing that could perhaps help things in the long run would be to\nexplicitly mark plumbing messages as not for translation. E.g. with a\n\"commit\" -> P_(\"commit\") macro.\n\nThat'd also give us something like the Documentation/ page you\nsuggest, but with only the plumbing messages extracted on a per-tool\nbasis (using the gettext tools). That'd probably make for a useful API\nreference.\n\nTo sum it up. I'm happy to amend something in the 5-point plan above,\nor to write new code to make the gettext series more acceptable. I\njust don't see what that something is.\n\nIn any case, thanks for all the work you and others have put into\ngetting the series into the state it's in today. I really appreciate it.\n"},{"id":"147356","messageId":"7viq3n73c6.fsf@alter.siamese.dyndns.org","threadId":"24643","inReplyTo":"AANLkTik1KVpb25nuwSFA2z4ezRJKWdTwRrS_KXzwM+2D@mail.gmail.com","subject":"Re: Cooking of the ab/i18n series","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-08-06T23:01:45Z","receivedAt":"2010-08-06T23:01:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> My mental plan for this series has basically been as follows:\n>\n> 1. Get it to a state where it can cook in pu [You Are Here]\n>\n> 2. After it's been there for a while get it to master\n>\n> 3. Once it's there for a while and we're sure the new dependency /\n> code doesn't harm some more obscure systems..\n>\n> 4. Start submitting patches to the main porcelain $(grep\n> 'mainporcelain common' command-list.txt) to make the most common\n> user-visible messages translatable.\n>\n> 5. Recruit translators to translate the strings in #4. Send\n> translations in as patches adding/altering the *.po files.\n\nMatches my expectations modulo s/master/next/. The stuff parked in 'pu'\nwas primarily because most of the work to get to this point was done\nduring the pre-release freeze for 1.7.2 and I didn't want to get\ndistracted, while I obviously did not lose patches.\n\n> Now, your main concern is that this doesn't break plumbing output....\n\nThat's not 'main'.\n\n'Breaking plumbing' is merely an example of a larger 'main concern' which\nis 'unintended consequences'.\n\nAnd please don't ask me to enumerate them exhaustively. By definition\n'unintended consequences' cannot be enumerated. They are discovered over\ntime either by code inspection, by people guinea-pigging a version outside\n'master', and by careful thinking.\n"},{"id":"147365","messageId":"AANLkTimvNgZ4UU595==Tx5i0LYF56ecNzvYWki0FM3u6@mail.gmail.com","threadId":"24643","inReplyTo":"7viq3n73c6.fsf@alter.siamese.dyndns.org","subject":"Re: Cooking of the ab/i18n series","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-08-07T01:13:47Z","receivedAt":"2010-08-07T01:13:47Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Aug 6, 2010 at 23:01, Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n>\n>> My mental plan for this series has basically been as follows:\n>>\n>>   1. Get it to a state where it can cook in pu [You Are Here]\n>>\n>>   2. After it's been there for a while get it to master\n>>\n>>   3. Once it's there for a while and we're sure the new dependency /\n>>      code doesn't harm some more obscure systems..\n>>\n>>   4. Start submitting patches to the main porcelain $(grep\n>>      'mainporcelain common' command-list.txt) to make the most common\n>>      user-visible messages translatable.\n>>\n>>   5. Recruit translators to translate the strings in #4. Send\n>>      translations in as patches adding/altering the *.po files.\n>\n> Matches my expectations modulo s/master/next/.\n\nYes, I meant to say \"on track to master\" (via next).\n\n> The stuff parked in 'pu' was primarily because most of the work to\n> get to this point was done during the pre-release freeze for 1.7.2\n> and I didn't want to get distracted, while I obviously did not lose\n> patches.\n\nI didn't mean to rush you, the delay is fine. It just sounded like the\nseries might be stuck in pu in perpetuity from the initial \"When\npeople see the benefit of doing so\" comment.\n\nBut if not, nevermind.\n\n>> Now, your main concern is that this doesn't break plumbing output....\n>\n> That's not 'main'.\n>\n> 'Breaking plumbing' is merely an example of a larger 'main concern' which\n> is 'unintended consequences'.\n\nSure, all code's going to have problems, and the ab/i18n series is\naround 1300 lines, so I'd be quite surprised if it didn't have some\nbug.\n\n> And please don't ask me to enumerate them exhaustively.  By definition\n> 'unintended consequences' cannot be enumerated.  They are discovered over\n> time either by code inspection, by people guinea-pigging a version outside\n> 'master', and by careful thinking.\n\nI was just wondering if there was anything particular that you were\nworried about that could be addressed.\n\nBut as you've clarified there's nothing about it that I should be\nexplicitly addressing before it can move forward (if I've understood\nyou correctly).\n\nThanks for clarifying that and for your time.\n"}]}