[PATCH i18n stable] i18n: fix untranslated prompts with translated responses (issue3936)

[Matt Mackall]

On Tue, 2013-05-21 at 21:50 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > On Mon, 2013-05-20 at 19:51 -0300, Wagner Bruna wrote:
> >> Em 16-05-2013 15:58, Matt Mackall escreveu:
> >> > On Wed, 2013-05-15 at 21:37 -0500, Kevin Bullock wrote:
> >> >> # HG changeset patch
> >> >> # User Kevin Bullock <kbullock at ringworld.org>
> >> >> # Date 1368671779 18000
> >> >> #      Wed May 15 21:36:19 2013 -0500
> >> >> # Branch stable
> >> >> # Node ID fc1c4221dd82de958b9be5f05c57622679625d21
> >> >> # Parent  278057693a1ddb93f95fa641e30e7a966ac98434
> >> >> i18n: fix untranslated prompts with translated responses (issue3936)
> >> > 
> >> > Queued for stable, thanks.
> >> > 
> >> > I'd like to see a consensus among translators on how to do this.
> >> 
> >> IMHO we should always accept the English keys, even with translated prompts
> >> (to help with muscle memory). And, ideally, detect conflicts at build_mo time.
> >> 
> >> > I also thing we should unify all the string args used by prompt() into a
> >> > single string so that translators have the full context.
> >> 
> >> Seems like a good approach (as long as we ensure there's no paragraph boundary
> >> on that single string, of course).
> >
> > Ok, here's a typical use:
> >
> >             elif repo.ui.promptchoice(
> >                 _("local changed %s which remote deleted\n"
> >                   "use (c)hanged version or (d)elete?") % f,
> >                 (_("&Changed"), _("&Delete")), 0):
> >
> > How shall we format this string to include all the components? Perhaps:
> >
> > _("local changed %s which remote deleted\n"
> >   "use (c)changed version or (d)elete?"
> >   "\f&Changed"
> >   "\f&Delete")
> >   
> > I think something like \f or \b (not \t) will work well as a separator
> > but I have no idea if our l10n tools will agree with me.
> 
> Gettext will warn when it sees an escape sequence other than \n and \t.
> It writes:
> 
>   warning: internationalized messages should not contain the `\f' escape
>   sequence

Bah.

> This was apparently introduced around 2005:
> 
>   http://lists.gnu.org/archive/html/bug-gnu-utils/2005-05/msg00065.html
> 
> I found another mail that explains the rationale a bit more: POT files
> are supposed to contain just \n and xgettext will apparently turn \r\n
> into \n in the POT file:
> 
>   http://lists.gnu.org/archive/html/bug-gnu-utils/2010-08/msg00021.html
> 
> When I quickly tested this, I found that a string with \f wasn't
> translated, despite showing up in the hg.pot file.

Huh.

> Would \t not be an easier choice here or are you afraid that it will be
> difficult for translators to produce a TAB character in the translation?

Mostly, I thought there was a possibility we might actually want to use
\t as a real tab, whereas I'm quite sure we'll never want to use \f.
Frankly, my first thought was \0.

I also don't want to preclude using any of the printing ASCII characters
either.

But now I'm reminded that we have Shift-JIS out there, which means we
can't reliably split translated strings on single ASCII bytes anyway.
Perhaps '$$' as the separator?

-- 
Mathematics is the supreme nostalgia of our time.