[Gnu-arch-users] Re: [BUG] i18n (Re: Message translation - basic framework)

[Stefan Monnier]

> What if the front-end could just always issue the command:

> "LANG=C tla <blah>"

> Or do it by setting the environment before the call, etc.

> Wouldn't that cause it to always report back non-internationalized messages?

Right.  But it could also have undesired side-effects (e.g. on programs run
by `tla' from hooks, ...).  It'd be better if it wasn't necessary.

> And if as a new front end you want to display the internationalized form,
> you can have your front end use the gettext() functionality to translate
> whatever messages you get. This also has the advantage that your front-end
> is part-way to being internationalized itself.

I'd much rather make sure the format is "redundant": the internationalized
text messages are always accompagnied with computer-readable info (could be
good old error-msg number or anything like that).

Using `gettext' from outside would be not just a real pain in the butt but
also generally not possible (you'd have to magically recover the format
string passed to printf).

> I think the best way is to get tla-2.0 librified and out the door so that
> you can have much more meaningful return values, without having to parse
> possibly ambiguous text. But in the mean-time it seems like frontends can
> easily work around the internationalization parsing problem.

Using a library rather than a binary executable is not always preferable
(or even an option), so while it's good to have a library, it doesn't mean
that the ability to do batch processing robustly is not needed.


        Stefan