[L10N] Kickoff of translation for Git 2.14.0 round 1

Hi,

Git v2.14.0-rc0 has been released, and it's time to start new round of git l10n. This time there are 30+ updated messages need to be translated since last update:

    l10n: git.pot: v2.14.0 round 1 (34 new, 23 removed)

    Generate po/git.pot from v2.14.0-rc0 for git v2.14.0 l10n round 1.

    Signed-off-by: Jiang Xin <worldhello.net@gmail.com>

You can get it from the usual place:

    https://github.com/git-l10n/git-po/

As how to update your XX.po and help to translate Git, please see "Updating a XX.po file" and other sections in “po/README" file.

-- Jiang Xin

Le 15/07/2017 à 07:06, Jiang Xin a écrit :

Hi all,

A few remarks on i18n:

 * commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for
timestamps") does not play well with i18n framework. The static string
concatenation cannot be correctly interpreted by msgmerge. I don't know
how we can combine variable format indicators with translatable strings.

 * commit 4ddb1354e8 ("status: contextually notify user about an initial
commit") plays sentence lego while introducing colorization which again
does not play well with i18n.

Thank you.

2017-07-16 3:30 GMT+08:00 Jean-Noël Avila <jn.avila@free.fr>:

We can add a new wrapper for raw timestamp like:

    +const char *format_raw_time(timestamp_t time)
    +{
    +       static struct strbuf time_buf = STRBUF_INIT;
    +
    +       strbuf_reset(&time_buf);
    +       strbuf_addf(&time_buf, "%"PRItime, time);
    +       return time_buf.buf;
    +}

, and replace macro PRItime in i18n messages with format_raw_time wrapper, like this:

    -                       strbuf_addf(&sb, Q_("%"PRItime" year",
"%"PRItime" years", years), years);
    +                       strbuf_addf(&sb, Q_("%s year", "%s years",
years), format_raw_time(years));

Hi,

On Mon, 17 Jul 2017, Jiang Xin wrote:

That would come at the price of complexifying the code just to accommodate a translation tool.

How do you gentle people deal with PRIuMAX?

Ciao, Dscho

2017-07-18 0:06 GMT+08:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

Can we just use PRIuMAX instead of the macro PRItime? PRIuMAX can be handled properly by gettext utilities, while PRItime not.

If replace PRItime to PRIuMAX like this:

    -                        Q_("%"PRItime" second ago", "%"PRItime"
seconds ago", diff), diff);
    +                        Q_("%"PRIuMAX" second ago", "%"PRIuMAX"
seconds ago", diff), diff);

The above l10n message can be extracted properly by running `make pot`:

    #: date.c:122
    #, c-format
    msgid "%<PRIuMAX> second ago"
    msgid_plural "%<PRIuMAX> seconds ago"
    msgstr[0] ""
    msgstr[1] ""

Commit cb71f8bdb5 ("PRItime: introduce a new "printf format" for timestamps", 2017-04-21) does not play well with i18n framework. The static string concatenation cannot be correctly interpreted by gettext utilities, such as xgettext.

Wrap PRItime in format_raw_time() function, so that we can extract correct l10n messages into "po/git.pot".

Reported-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
 archive-zip.c          |  4 ++--
 builtin/blame.c        |  4 ++--
 builtin/fsck.c         |  3 ++-
 builtin/log.c          |  4 ++--
 builtin/receive-pack.c |  4 ++--
 builtin/rev-parse.c    |  2 +-
 cache.h                |  1 +
 date.c                 | 63 ++++++++++++++++++++++++++++++++------------------
 fetch-pack.c           |  2 +-
 refs/files-backend.c   |  6 ++---
 upload-pack.c          |  2 +-
 vcs-svn/fast_export.c  |  8 ++++---
 12 files changed, 63 insertions(+), 40 deletions(-)

Jiang Xin <worldhello.net@gmail.com> writes:

Hmm.

Two potential issues are:

 - After this patch, there still are quite a many 

	printf("time is %"PRItime" ...\n", timestamp)

   so the burden on the programmers having to remember when it is
   required to use format_raw_time() becomes unclear, and makes the
   change/churn larger when an existing message needs to be marked
   for translation.

 - The static struct strbuf here is a cheap way to avoid leaks, but
   at the same time it is unfriendly to threaded code.  We could
   instead do:

        void append_PRItime(struct strbuf *buf, timestamp_t time);

   to fix that trivially, but the damage to the caller obviously is
   much larger going this way.

2017-07-18 1:10 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

I wonder if we can replace the original %lu for timestamp with PRIuMAX instead. PRIuMAX works fine with gettext utils.

Jiang Xin <worldhello.net@gmail.com> writes:

I think the question can better be answered if we know how gettext tools special case PRIuMAX. One thing that may be problematic is that timestamp can later become a signed type and use of one level of redirection in the current code via PRItime and via timestamp_t is a good way to keep such a transition much easier. Reverting it to use PRIuMAX would make such a transition much harder.

2017-07-19 1:35 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

Gettext handles macros such as PRIuMAX in commit 8b45c5df1 ("Add support for ISO C 99 <inttypes.h> format string directive macros.", 2002-07-23 12:33:13 +0000).

Macros such as PRIuMAX are hard coded, and we can not hack gettext easily and directly.

For example, some code in commit 8b45c5df1 (see: See: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=8b45c5df18e1976a1275297db73978bfe6144c7e):

    +/* 8a. Convert ISO C 99 section 7.8.1 format string directives to string
    +   literal placeholders.  */
    +
    +/* Test for an ISO C 99 section 7.8.1 format string directive.  */
    +static bool
    +is_inttypes_macro (name)
    +     const char *name;
    +{
    +  /* Syntax:
    +     P R I { d | i | o | u | x | X }
    +     { { | LEAST | FAST } { 8 | 16 | 32 | 64 } | MAX | PTR }  */
    +  if (name[0] == 'P' && name[1] == 'R' && name[2] == 'I')
    +    {
    +      name += 3;
    +      if (name[0] == 'd' || name[0] == 'i' || name[0] == 'o' ||
name[0] == 'u'
    +          || name[0] == 'x' || name[0] == 'X')
    +        {
    +          name += 1;
    +          if (name[0] == 'M' && name[1] == 'A' && name[2] == 'X'
    +              && name[3] == '\0')
    +            return true;
    +          if (name[0] == 'P' && name[1] == 'T' && name[2] == 'R'
    +              && name[3] == '\0')
    +            return true;
    +          if (name[0] == 'L' && name[1] == 'E' && name[2] == 'A'
    +              && name[3] == 'S' && name[4] == 'T')
    +            name += 5;
    +          else if (name[0] == 'F' && name[1] == 'A' && name[2] == 'S'
    +                   && name[3] == 'T')
    +            name += 4;
    +          if (name[0] == '8' && name[1] == '\0')
    +            return true;
    +          if (name[0] == '1' && name[1] == '6' && name[2] == '\0')
    +            return true;
    +          if (name[0] == '3' && name[1] == '2' && name[2] == '\0')
    +            return true;
    +          if (name[0] == '6' && name[1] == '4' && name[2] == '\0')
    +            return true;
    +        }
    +    }
    +  return false;
    +}

    + if (*format == '<')
        {
    -     if (*format == 'h')
    +     spec.c99_directives =
    +       (const char **)
    +       xrealloc (spec.c99_directives,
    +                 2 * (spec.c99_directives_count + 1)
    +                 * sizeof (const char *));
    +     spec.c99_directives[2 * spec.c99_directives_count] = format;
    +
    +     format++;
    +     /* Parse ISO C 99 section 7.8.1 format string directive.
    +        Syntax:
    +        P R I { d | i | o | u | x | X }
    +        { { | LEAST | FAST } { 8 | 16 | 32 | 64 } | MAX | PTR }  */
    +     if (*format != 'P')
    +       goto bad_format;
    +     format++;
    +     if (*format != 'R')
    +       goto bad_format;
    +     format++;
    +     if (*format != 'I')
    +       goto bad_format;
    +     format++;
    +
    +     switch (*format)
    +       {
    +       case 'i': case 'd':
    +         type = FAT_INTEGER;
    +         break;
    +       case 'u': case 'o': case 'x': case 'X':
    +         type = FAT_INTEGER | FAT_UNSIGNED;
    +         break;
    +       default:
    +         goto bad_format;
    +       }
    +     format++;
    +
    +     if (format[0] == 'M' && format[1] == 'A' && format[2] == 'X')
    +       {
    +         type |= FAT_SIZE_INTMAX_T;
    +         format += 3;
    +       }
    +     else if (format[0] == 'P' && format[1] == 'T' && format[2] == 'R')

Hi Jian (or is it Xin?),

On Wed, 19 Jul 2017, Jiang Xin wrote:

Wow. This is ugly.

If I understand correctly, then this will not even work correctly for PRIuMAX on Windows: I highly doubt that the gettext library will interpret %I64u in the format string correctly to be what %<PRIuMAX> in the po file refers to.

But there may be hope. Since the character sequence "PRItime" is highly unlikely to occur in Git's source code in any context other than the format to print/parse timestamp_t, it should be possible to automate a the string replacement

	git ls-files -z \*.[ch] |
	xargs -0r sed -i 's/PRItime/PRIuMAX/g'

(assuming, of course, that you use GNU sed, not BSD sed, for which the `-i` needs to read `-i ''` instead) as part of the update?

For all the reasons Junio mentioned, I, too, would be reluctant to change the source code to cull all of the PRItime mentions, as it is pleasing from a semantic point of view that we know what the heck we are talking about here.

BTW *thank you so much* for your Herculean effort to keep going with the translation.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I think it is the other way around. Without such a special-casing, and producing message identifier that has "%<PRIuMAX>" in it, they cannot get a .po source that is usable across platforms.

Imagine a hypothetical xgettext that does not have the special case, but just does what CPP does. Running it on a platform where uintmax_t is "unsigned long" would have "%lu" in resulting .po for a message that uses "%" + PRIuMAX. But the same source compiled on a platform where uintmax_t is larger would pass "%llu" in calls to _(...) it makes; such a string will not be found at runtime in the corresponding .mo file, because you started with "%lu" in the .po file. By leaving a special marker %<PRIuMAX> in the .po file by special casing, the toolchain can make sure that the actual parameter given to a _(...) can be found at runtime in .mo file that was produced by compiling the .po file for the target platform.

So our own PRItime was a good idea for maintainability's point of view of _our_ code, but it was not very friendly to i18n.

I can see two possibly usable approaches to make it i18n-friendly while retaining our ability to later change the underlying type of timestamp_t. But neither is very pretty.

 - One is what was in Jiang's earlier proposal.

 - Another is to replace PRItime with PRIuMAX _but_ leave a comment
   to tell us that it wanted to be PRItime, so that we can later
   "git grep" for such a comment if/when we want to update the type
   of timestamp_t.

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I somehow missed this bit.

Given that this needs to be done only once every release by only one person (i.e. the l10n coordinator who updates *.pot file), as long as the procedure is automated as much as possible to ease the pain for the l10n coordinator and clearly described in the "Maintaining the po/git.pot file" section of po/README, something along that line does sound like a very tempting approach. If it works well, it is certainly much easier for normal developers than the other possible alternatives I mentioned in my previous response.

It is brittle as you already said, but perhaps a bit of anchoring like \<PRItime\>, the brittle-ness may not hurt in practice.

I didn't look at "git grep PRItime" output for hits, though.

Junio C Hamano <gitster@pobox.com> writes:

So, I was offline for most of the day yesterday and with this issue blocking the release candidate, didn't manage to tag -rc1.

The use of "make pot" from the top-level is already described in po/README, so the only thing that we need is something like this change. I'll follow up this message with a sample output from the updated process to ask others to sanity check the result (they are tiny) in a separate message.

Thanks.

 Makefile | 10 ++++++++++
 1 file changed, 10 insertions(+)

Junio C Hamano <gitster@pobox.com> writes:

Without the Makefile patch in the previous message, I ran "make pot" and saved the resulting po/git.pot to git.pot-old. And then after "git reset --hard", I applied the Makefile patch and ran "make pot" again, which gave me an updated po/git.pot file. The difference is shown below.

As expected, these look sensible to me.  All the hits from 

	git grep '_(.*PRItime'

are included in the difference.

--- git.pot-old 2017-07-20 11:17:29.608343390 -0700 +++ po/git.pot 2017-07-20 11:18:14.744342564 -0700

So I am inclined to apply this directly on 'master' before tagging the first release candidate that includes timestamp_t; I'll wait for the earth to rotate once for comments, though.

Thanks.

-- >8 --
Subject: [PATCH] Makefile: help gettext tools to cope with our custom PRItime format

We started using our own timestamp_t type and PRItime format specifier to go along with it, so that we can later change the underlying type and output format more easily, but this does not play well with gettext tools.

Because gettext tools need to keep the *.po file portable across platforms, they have to special-case the format specifiers like PRIuMAX that are known types in inttypes.h, instead of letting CPP handle strings like

    "%" PRIuMAX " seconds ago"

as an ordinary string concatenation. They fundamentally cannot do the same for our own custom type/format.

Given that po/git.pot needs to be generated only once every release and by only one person, i.e. the l10n coordinator, let's update the Makefile rule to generate po/git.pot so that gettext tools are run on a munged set of sources in which all mentions of PRItime are replaced with PRIuMAX, which is what we happen to use right now.

This way, developers do not have to care that PRItime does not play well with gettext, and translators do not have to care that we use our own PRItime.

The credit for the idea to munge the source files goes to Dscho. Possible bugs are mine.

Helped-by: Jiang Xin <worldhello.net@gmail.com>
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Makefile | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

Le 20/07/2017 à 20:57, Junio C Hamano a écrit :

Does PRIuMAX make sense for perl and sh files?

Jean-Noël Avila <jn.avila@free.fr> writes:

Not really; I did this primarily because I would prefer to keep things consistent, anticipating there may be some other things we need to replace before running gettext(1) for other reasons later.

I do not mind removing them, if Jiang/Dscho already reviewed and tested _this_ version (which we do not yet know), I'd prefer not to touch it for the upcoming release.

Thanks for reading it over.

Hi,

On Fri, 21 Jul 2017, Junio C Hamano wrote:

It would add unnecessary churn, too, to add those specific exclusions and make things inconsistent: the use of PRItime in Perl or shell scripts would already make those scripts barf. And if it is unnecessary churn... let's not do it?

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Sorry, but I cannot quite tell if you are in favor of limiting the set of source files that go through the sed substitution (because we know PRIuMAX is just as nonsensical as PRItime in perl and shell source), or if you are in favor of keeping the patch as-is (because changing the set of source files is a churn and substitutions would not hurt)?

I am actually OK to change the above loop to process only the C sources; I am not OK to change it to process only date.c which happens to be the only source that has PRItime that matters in this context, of course.

Thanks.

Hi Junio,

On Sat, 22 Jul 2017, Junio C Hamano wrote:

I was in favor of keeping the simplest strategy: simply cover all files, including Perl and Unix shell scripts. It would not bring any benefit to exclude them.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

OK. I actually was OK to limit the potential damage to C sources, but it does not matter that much in the bigger picture.

2017-07-21 2:19 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

Sorry, I'm late. I want to try a safer way to change PRItime to PRInMax using a hacked version of gettext.

We can change Makefile like this:

    --- a/Makefile
    +++ b/Makefile
    @@ -2216,7 +2216,14 @@ LOCALIZED_SH += t/t0200/test.sh
     LOCALIZED_PERL += t/t0200/test.perl
     endif

    -po/git.pot: $(GENERATED_H) FORCE
    +check_gettext:
    +       @if ! $(XGETTEXT) --version | grep -q -i PRItime; then \
    +               echo >&2 "Error: must use a hacked xgettext, which
can handle PRItime macro properly."; \
    +               echo >&2 "Error: download the hacked version of
gettext from https://github.com/......" ; \
    +               exit 1; \
    +       fi
    +
    +po/git.pot: check_gettext $(GENERATED_H) FORCE
           $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ $(XGETTEXT_FLAGS_C) $(LOCALIZED_C)
           $(QUIET_XGETTEXT)$(XGETTEXT) -o$@+ --join-existing
$(XGETTEXT_FLAGS_SH) \
                   $(LOCALIZED_SH)

But I'm not sure I can handle this in this very busy weekend.

Jiang Xin <worldhello.net@gmail.com> writes:

Why? A vanilla version of gettext tool that is fed a known PRIuMAX in its input would be a safer choice, I would have thought.

I've already queued the patch you responded to on 'master', but haven't tagged -rc1 yet, so it is possible for you to update on top of it before -rc1 is tagged. I do not yet understand why you think a modified version of gettext would be a safer way to go, though.

Thanks.

2017-07-22 6:40 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

A very small hack on gettext. When extract l10n messages to pot file with `xgettext`, will grep "PRItime", and do "sed s/PRItime/PRIuMAX" inside `xgettext`.

See this patch: https://github.com/jiangxin/gettext/commit/b0a726431c93b5a1ca0fe749de376b0752e75fb0

    ---
     gettext-tools/src/x-c.c      | 17 ++++++++++++++++-
     gettext-tools/src/xgettext.c |  2 +-
     2 files changed, 17 insertions(+), 2 deletions(-)

    diff --git a/gettext-tools/src/x-c.c b/gettext-tools/src/x-c.c
    index 1844a5df7..51dd0a9bc 100644
    --- a/gettext-tools/src/x-c.c
    +++ b/gettext-tools/src/x-c.c
    @@ -1802,6 +1802,12 @@ phase6_unget (token_ty *tp)
     static bool
     is_inttypes_macro (const char *name)
     {
    +  /* PRItime is a maro for timestamp_t in git.git. */
    +  if (!strncmp(name, "PRItime", 7))
    +    {
    +      return true;
    +    }
    +
       /* Syntax:
          P R I { d | i | o | u | x | X }
          { { | LEAST | FAST } { 8 | 16 | 32 | 64 } | MAX | PTR }  */
    @@ -1843,8 +1849,17 @@ phase8a_get (token_ty *tp)
       phase6_get (tp);
       if (tp->type == token_type_name && is_inttypes_macro (tp->string))
         {
    +      char *new_string;
           /* Turn PRIdXXX into "<PRIdXXX>".  */
    -      char *new_string = xasprintf ("<%s>", tp->string);
    +      if (!strncmp(tp->string, "PRItime", 7))
    +        {
    +          /* Replace PRItime with PRIuMAX for git.git project */
    +          new_string = xasprintf ("<%s>", "PRIuMAX");
    +        }
    +      else
    +        {
    +          new_string = xasprintf ("<%s>", tp->string);
    +        }
           free (tp->string);
           tp->string = new_string;
           tp->comment = add_reference (savable_comment);
    diff --git a/gettext-tools/src/xgettext.c b/gettext-tools/src/xgettext.c
    index f848d76d1..0350a1bee 100644
    --- a/gettext-tools/src/xgettext.c
    +++ b/gettext-tools/src/xgettext.c
    @@ -676,7 +676,7 @@ main (int argc, char *argv[])
       /* Version information requested.  */
       if (do_version)
         {
    -      printf ("%s (GNU %s) %s\n", basename (program_name),
PACKAGE, VERSION);
    +      printf ("%s (GNU %s) %s (PRItime to PRIuMAX for
git.git)\n", basename (program_name), PACKAGE, VERSION);
           /* xgettext: no-wrap */
           printf (_("Copyright (C) %s Free Software Foundation, Inc.\n\
     License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>\n\
    --
    2.14.0.rc0.1.g3ccfa2fb49

Jiang Xin <worldhello.net@gmail.com> writes:

I do not think the size of the "hack" is much of an issue. There is no way you can sell this patch to the upstream, which would mean that we would have to be relying on our own private edition of the external tool, and that is what I feel very uncomfortable about.

You are not passing %<PRItime> through the toolchain and instead turning it into %<PRIuMAX>, which is less risky than the obvious alternative, but when we switch to a signed timestamp_t type and need to change it something else (e.g. PRIdMAX), you'd need to make sure you update that private edition that matches the source being compiled. You might even be asked to do the po/git.pot thing for both 'maint' and 'master' at the same time, when the former still uses unsigned timestamp_t while the latter switched to signed one, which would mean you'd need two hacked versions of gettext handy and choose the "right" one.

Compared to that, Dscho's "hack" at least ties what PRItime is replaced with and what the source code says by being in the Makefile, which is tracked alongside the rest of the source. So I somehow feel that the approach has smaller chance of going wrong.

Am I missing some concerns you had that you think the tweaked gettext would solve better?

2017-07-22 7:34 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

I never think about that, and I won't sell it to the upstream. ;)

That's why I grep "PRItime to PRIuMAX" from `xgettext --version`. When we need something else, we can tweak the "check-xgettext" task again in Makefile, to match with a grep-"PRItime to PRIdMAX" version of `xgettext`.

But it is rare to maintain po/git.pot file for 'maint' branch. And if I need, I will switch to a different version of gettext. Makefile will throw a error message, if I use a wrong version of gettext.

Benefit of using the tweak version of gettext:

1. `make pot` can be run in a tar extract directory (without git controlled).
2. do not need to run `git reset --hard`.
3.  it's quick (nobody cares).

Instead of doing a sed (s|PRItime|PRIuMAX) in working tree directly, we can use a tweaked version of gettext, which can replace PRItime macro to PRIuMAX (version 1.x) in runtime. We do not need to reset our working tree anymore, and this operation can be run without a version controlled working tree.

The tweaked version of gettext is hosted at:

    https://github.com/jiangxin/gettext

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
---
 Makefile | 29 ++++++++++-------------------
 1 file changed, 10 insertions(+), 19 deletions(-)

Jiang Xin <worldhello.net@gmail.com> writes:

Is that the "v1" in the check in your Makefile patch is about? That is, when we need to change the underlying type, your updated gettext would say something different from "v1" and you will have Makefile update to expect that new version? Then it would be workable, I'd guess.

This is about a tool and workflow only you (and your successor, when the time comes) need to use, so ultimately I'd prefer to leave it up to you, but I'd want to make sure you are making your decision with sound rationale. I personally do not think 1. and 2. above are real issues in practice, because (1) you'd be committing the result of "make pot" so that translators can work off of it---which at least to me means that being able to run on a tarball extract is not a useful feature, and (2) when you are about to run xgettext to extract strings from the message, you do not want to have local modifications, extracting potentially modified strings with potentially offset line numbers in the resulting pot file, so having to run "git reset --hard" at the end is not a problem.

I do not know if 3. is a practical issue or not (I did try "make pot" with the tip of 'master' tonight myself, and I didn't find it much slower than the unmodified one).

Having said all that, again, I'd prefer to leave this up to you, so unless I hear that you changed your mind, the tip of 'master' I'll tag, probably sometime tomorrow my time, will have your patch to the Makefile to rely on your private edition of xgettext.

Thanks.

Hi,

On Sat, 22 Jul 2017, Jiang Xin wrote:

I am 100% opposed to this hack. It is already cumbersome enough to find out what is involved in i18n (it took *me* five minutes to find out that much of the information is in po/README, with a lot of information stored *on an external site*, and I still managed to miss the `make pot` target).

If at all, we need to make things easier instead of harder.

Requiring potential volunteers to waste their time to compile an unnecessary fork of gettext? Not so great an idea.

Plus, each and every Git build would now have to compile their own gettext, too, as the vanilla one would not handle the .po files containing %<PRItime>!!!

And that requirement would impact instantaneously people like me, and even worse: some other packagers might be unaware of the new requirement which would not be caught during the build, and neither by the test suite. Double bad idea.

So let's go with Junio's patch.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

If I understand correctly, the patch hacks the input processing of xgettext (which reads our source code and generates po/git.pot) so that when it sees PRItime, pretend that it saw PRIuMAX, causing it to output %<PRIuMAX> in its output.

In our workflow, 

    * The po/git.pot file is updated only by the l10n coordinator,
      and then the result is committed to our tree.

    * Translators build on that commit by (1) running msgmerge which
      takes po/git.pot and wiggles its entries into their existing
      po/$lang.po file so that po/$lang.po file has new entries from
      po/git.pot and (2) editing po/$lang.po file.  The result is
      committed to our tree.

    * The build procedure builders use runs the resulting
      po/$lang.po files through msgfmt to produce po/$lang.mo files,
      which will be installed.

As long as the first step results in %<PRIuMAX> (not %<PRItime> or anything that plain vanilla msgmerge and msgfmt do not understand), the second step and third step do not require any hacked version of gettext tools.

Even though I tend to agree with your conclusion that pre-processing our source before passing it to xgettext is probably a better solution in the longer term, I think the most of the objections in your message come from your misunderstanding of what Jiang's patch does and are not based on facts. My understanding is that translators do not need to compile a custom msgmerge and builders do not need a custom msgfmt.

2017-07-22 23:48 GMT+08:00 Junio C Hamano <gitster@pobox.com>:

I appreciate Junio's explanation. I totally agree.

Hi,

On Sat, 22 Jul 2017, Junio C Hamano wrote:

Oh, I missed that. That's even worse, as it precludes what you were wishing for: to replace timestamp_t by a signed data type eventually.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Yup, Jiang's plan was to update the custom edition of xgettext when it happens and the Makefile patch has a provision to avoid mistakes.

If Jiang's patch were extended so that xgettext would take a command line option "--custom-priformat=PRItime=PRIuMAX" and upstreamed and wildy deployed already, that would have been a good solution. That might be a preferred outcome that may benefit other projects, but it won't happen for at least 3 years if not more X-<.

2017-07-22 19:28 GMT+08:00 Johannes Schindelin <Johannes.Schindelin@gmx.de>:

It's really very small, see:

*  https://github.com/jiangxin/gettext/commit/b0a72643
*  https://public-inbox.org/git/a87e7252bf9de8a87e5dc7712946f72459778d6c.1500684532.git.worldhello.net@gmail.com/

If it is only the l10n coordinate's duty to generate po/git.pot, the tweak is OK. But if other guys need to recreate po/git.pot, it's hard, especially for guys working on Mac or Windows.

No, only l10n coordinator and potential po/git.pot generator are involved.

I agree. We just go with the sed-then-cleanup version until we meet ambiguities (I mean some words other than PRItime need to be replaced).

Jiang Xin <worldhello.net@gmail.com> writes:

OK, thanks for all involved to get us to a conclusion. Jiang, I saw you already made an announcement for the second round. Thank you very much for doing so without waiting me---I was stuck on something else and my morning was blown X-<. I'll still try to tag -rc1 by the end of business today.

Hi,

On Mon, 24 Jul 2017, Jiang Xin wrote:

I don't care about size. Insecure, pampered white men may be concerned about size; not I.

I am concerned about an *unnecessary* deviation from a well-established and well-maintained piece of software that would all of a sudden be version-coupled with Git.

No. You want to keep the bus number high.

Even then. Even then you should want to avoid version-coupling Git versions with gettext versions. Because that's precisely what you would do, as gettext would now have to know about *this* Git version's interpretation of certain data type names.

Ciao, Dscho

Le 22/07/2017 à 02:43, Jiang Xin a écrit :

This issue is real for packet maintainers who can patch the original source and run their own set of utilities outside of a git repo. This can be possible with Junio's proposition by writing the files to a temporary directory before running the xgettext, then removing the temporary directory.

Please note that with respect to this issue, the patched xgettext approach is completely disruptive.

Same as before.

Requiring patched tools is really breaking collaboration. Git made a great case of relying on standard tools (not even GNU versions), so that would really go backward.

Plus, I hope that some day, instead of translators finding afterwards that a change broke i18n capabilities, developpers would have some kind of sanity check. Requiring special versions of i18n tooling stops this hope.

begin:vcard fn;quoted-printable:Jean-No=C3=ABl AVILA n;quoted-printable:AVILA;Jean-No=C3=ABl org:SCANTECH FRANCE adr;quoted-printable:Savoie Technolac, BP244;;34, All=C3=A9e du Lac d'Aiguebelette;Le Bourget du Lac;;73374;FRANCE email;internet:jean-noel.avila@scantech.fr title:Embedded Systems Manager tel;work:+33 479265450 tel;cell:+33 633046418 x-mozilla-html:FALSE url:http://www.scantech.fr version:2.1 end:vcard

Jean-Noël AVILA <jean-noel.avila@scantech.fr> writes:

OK, so what you are saying is that my assumption that Jiang (at least for now, and his successor l10n coordinator in sometime in the future) would be the only one who needs to have access to the machinery to update po/git.pot and that it does not matter that much what that exact machinery is as long as the resulting po/git.pot lists messages with %<PRIuMAX> and other known ones because plain vanilla tools will grok such po/git.pot file just fine, were both too optimistic.

I think binary packagers, who update the software with their own changes, produce their own modified po/git.pot and have that translated into multiple languages, are capable of coping with any method we use ourselves, but being capable of doing something and being happy to do that thing are two different things, and we need to aim for the latter---we should not make things unnecessarily cumbersome for them.

So I'll leave the s/PRItime/PRIuMAX/ patch in the 'master' without Jiang's change for 2.14-rc1. The approach to require private edition of xgettext, while it may technically be a fun exercise, would not fly very well in the real world.

For those who want to work with a tarball extract without being in a Git repository, it would be sufficient fot them to run "git init && git commit --allow-empty -m import" immediately after extracting the tarball, even if we require that "make pot" must be run in a clean repository. And I'd prefer to go that route than copying into a temporary directory, primarily because I do not want to having to worry about what to copy---when we know we pass $foo.c through xgettext, we know we want to put the modified copy of $foo.c in the temporary, but I do not want to even think if we need to also copy the header files $foo.c "#include"s, for example.

Thanks.

2017-07-23 10:33 GMT+08:00 Jean-Noël AVILA <jean-noel.avila@scantech.fr>:

It would be fun to create some tools to help l10n guys finding l10n changes on every git commit.

Jiang Xin <worldhello.net@gmail.com> writes:

It is not just fun but would be useful, I would think.

On Sat, 2017-07-15 at 21:30 +0200, Jean-Noël Avila wrote:

What, if anything, should be done about this?

Le 22/07/2017 à 19:02, Kaartic Sivaraam a écrit :

I only spotted it because the string is new for translation. But the previous version was already playing sentence lego. So this is not a regression ;-)

If I understand correctly, getting a i18n friendly string would require being able to "color_sprintf" the branche name, and then "color_fprintf" the output with a %s formatting string. None of this is already available and that would introduce cumbersome logic in the code.

More generally, i18n puts some pressure on coding style for sure, and it gets worse with multi-platform and coloring... how can we ease the burden of developpers on this front without resorting to ad hoc patches?

El 15/07/2017 a les 07:06, Jiang Xin ha escrit:

Hello Jiang,

Sometimes I do several commits to complete the translation. However, github from the UI does not offer me the option to Merge and Squash.

Can you check that you have "Allow squash merging" activated for the https://github.com/git-l10n/git-po repository?

Allowing this from the Github UI will make life more easy.

Thanks,

Jordi,

2017-07-19 13:44 GMT+08:00 Jordi Mas <jmas@softcatala.org>:

Yes, it was activated. But I doubt the commit log of the squash merge won't follow our standard.

For me, I prefer doing an interactive rebase and squashing all the commits into one, and will record the contributors in header of the file and in the commit log message.