Re: [Monotone-devel] resend : i18n

[Nathaniel Smith]

On Fri, Aug 19, 2005 at 05:28:29AM +0200, Beno?t Dejean wrote:
> Hi, i'm starting French translation of monotone. I'm attaching patchs
> that add needed files and fixes some string usage.

Thanks a lot!  We'd love to be more fully i18nized, but without more
experience with it ourselves, it's hard to do unless people offer some
expertise... much appreciated!

> F() is used everywhere which is fine, but not for i18n people. Most of
> the 800 strings are not intented to user. There's also a lot of code
> that does string surgery (see example in the patch). To fix this you(we)
> need to :
> - use F() everywhere
> - split F() and _() / N_() / ngettext()
> - some strings ends with a \n, many don't. This is a bit messy.

It seems clear that F() is not actually the optimal marker for
i18nable text; in particular, it's sometimes used to do things like
build SQL strings... (though these could use boost::format directly, I
suppose...)

My biggest concern for i18n is that we come up with some mechanism
where we don't have to explicitly mark each W, P, etc.; there's too
much room for mistakes.  There are a few ways one could do this; here
are two:
  P(_F("foo %s baz") % bar);
    make a special type of formatter that is i18nized; use the type
    system to enforce that user-printed commands take i18nized
    strings.
  P("foo %s baz", "bar")
    move the formatter inside the P(); call gettext there

A question is how to handle ngettext for these purposes... maybe
  P(_FP("%i foo", "%i foos", n), n)
or
  PP("%i foo", "%i foos", n, n)
?  (FP/PP for "format plural"/"print plural")

Another question is what to do with log messages, the L() macro.  Logs
are only displayed when run with --debug or after a crash; they are
more intended for developers than for users, so this might argue for
leaving them in English (since that's the language of development), so
crash reports are always intelligible.  OTOH, --debug can be quite
handy to users to figure out what's going on at times...

> Moreover, many user strings are currently not marked for i18n, such as
> help/usage.

Right, should be fixable.

> -  setlocale(LC_CTYPE, "");
> -  setlocale(LC_MESSAGES, "");
> +  setlocale(LC_ALL, "");
>    bindtextdomain(PACKAGE, LOCALEDIR);
>    textdomain(PACKAGE);
>  
> @@ -257,9 +256,8 @@
>      L(F("command line: %s\n") % cmdline_ss.str());
>    }
>  
> -  L(F("set locale: LC_CTYPE=%s, LC_MESSAGES=%s\n")
> -    % (setlocale(LC_CTYPE, NULL) == NULL ? "n/a" : setlocale(LC_CTYPE, NULL))
> -    % (setlocale(LC_MESSAGES, NULL) == NULL ? "n/a" : setlocale(LC_MESSAGES, 
> NULL)));
> +  L(F("set locale: LC_ALL=%s\n")
> +    % (setlocale(LC_ALL, NULL) == NULL ? "n/a" : setlocale(LC_ALL, NULL)));

Applied.

>    if (app.db.private_key_exists(ident))
>      {
>        P(F("dropping private key '%s' from database\n\n") % ident);
> -      W(F("the private key data may not have been erased from the"));
> -      W(F("database. it is recommended that you use 'db dump' and"));
> -      W(F("'db load' to be sure."));
> +      W(F("the private key data may not have been erased from the"
> +          "database. it is recommended that you use 'db dump' and"
> +          "'db load' to be sure."));
>        app.db.delete_private_key(ident);
>        key_deleted = true;
>      }

Applied (but with \n's inserted, which the string breaks were
implicitly inserting).

[...more changes...]

Didn't apply any of the rest until we have a slightly better idea what
strategy we plan to take for marking strings.

Would you like commit access, so you can update the translation
directly?

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."