git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Stable ab/i18n branch

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Oct 19, 2010, 06:05 UTC
Message-ID
<4CBD352A.8040304@drmicha.warpmail.net>
In-Reply-To
<7vmxqb2hqk.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 19.10.2010 01:39:
Show 49 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
>> Do you mean to re-arrange it so that there's a patch at the front of
>> the series that introduces gettext.h with only the fallbacks:
>>
>>     #define _(s) (s)
>>     #define N_(s) (s)
>>
>> And then merge the ~120 gettextize patches first and do the
>> infrastructure later?
> 
> Not really.
> 
> Two pieces that would be nice to have in 'master' (or even 'maint', if we
> consider avoiding merge conflicts and mismerges when fixes are queued
> there) are:
> 
>  1. preparatory fixes to code that builds message string by concatenating
>     parts of speech in English word ordering into buffer or emitting to
>     output stream piece by piece; they should convert them to some form of
>     sprintf-like format strings plus arguments.  This does not necessarily
>     have to mark the format strings with _(s).
> 
>  2. the empty definitions for _(s) and N_(s).
> 
> I would consider the first one part of general clean-up job, which we know
> will help i18n, but which we would want to do regardless of i18n.  And it
> is probably the most error prone part in the whole process.  The sooner
> the result of these two steps hit 'master', the less pain for everybody.
> 
> And then:
> 
>  3. actual marking of strings with _(s) and N_(s).
> 
> which can be merged to 'next' after vetting for regression (the first two
> classes).
> 
>  4. Adding and polishing of *.po files for actual messages and languages,
>     i.e. l10n.
> 
> This can happen pretty much independently from 3.  Honestly I would be
> happier if I do not have to keep track of the actual l10n part.
> 
> I think the current series to some degree conflates steps 1. and 3.  As
> the list of risks I outlined in the previous message show, mistakes in 1.
> is much more grave than mistakes in 3. (iow, no big deal for having a few
> untranslated messages during early rounds of i18n support); I would have
> preferred these two steps were clearly separated, so that we can push the
> first two steps out to the 'master' sooner.

I'd just like to second (or third or..) Junio's points here since I had suggested a split like that earlier already, and I think the current state of affairs simply makes many potential reviewers (at least one that I know of) go away.

1.,2. and (maybe to a lesser degree) also 3. should be able to find many reviewers, thus making the potentially problematic parts as solid as possible. (I'm still waiting for a conceptual approach to 4., i.e. glossary first, but that is a different issue.)

Michael
Previous: Junio C HamanoNext: Junio C Hamano
Message 19 of 21 in “What's cooking in git.git (Oct 2010, #01; Wed, 13)”
  1. Junio C HamanoOct 14, 2010
  2. Nazri RamliyOct 14, 2010
  3. Ævar Arnfjörð BjarmasonOct 14, 2010
  4. Stable ab/i18n branchJonathan Nieder, Oct 14, 2010
  5. Ævar Arnfjörð BjarmasonOct 14, 2010
  6. Jonathan NiederOct 14, 2010
  7. Ævar Arnfjörð BjarmasonOct 14, 2010
  8. Sverre RabbelierOct 14, 2010
  9. Jon SeymourOct 14, 2010
  10. Ævar Arnfjörð BjarmasonOct 15, 2010
  11. Jonathan NiederOct 15, 2010
  12. Ævar Arnfjörð BjarmasonOct 15, 2010
  13. Jonathan NiederOct 15, 2010
  14. Ævar Arnfjörð BjarmasonOct 15, 2010
  15. Junio C HamanoOct 17, 2010
  16. Ævar Arnfjörð BjarmasonOct 17, 2010
  17. Jonathan NiederOct 17, 2010
  18. Junio C HamanoOct 18, 2010
  19. Michael J GruberOct 19, 2010
  20. Junio C HamanoOct 17, 2010
  21. Johan HerlandOct 21, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.