[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [BUG] i18n (Re: Message translation - basic framewo
[Gnu-arch-users] Re: [BUG] i18n (Re: Message translation - basic framework)
Mon, 06 Dec 2004 15:22:53 -0500
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)
> 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.