A stxtinfo localization

[Karvjorm]

Here is a stxtinfo localization patch.

[Karvjorm]

A stxtinfo localization patch

[pulkomandy]

We don't localize CLI applications.

[Barrett]

No idea if this ticket makes sense, actually it's bad pratice to localize CLI apps. Getting out from R1 at least.

[Karvjorm]

Many Linux CLI apps are localized.

[Barrett]

The main problem is that we have already a lot of work on localizing the whole system, since CLI apps are supposed to be used by an expert user, I'm not sure if it makes sense right now to localize them.

I'm not generally against it, but not particularly in favor of, at least I can live without it.

If you want you can start a discussion in the haiku-dev mailing list, if there's a general agreement I'll commit your patches. Don't take it as a refusal :-), I've commented just because I've considered whether to apply your changes.

[pulkomandy]

The discussion already happened when the patch was submitted IIRC, and some arguments against localizing CLI apps were raised:

• It makes it harder to parse/script the output, sometimes in non-obvious ways (you don't expect a date format to change, etc)
• It makes it more difficult to "remote debug" someone (let's say a russian user asks for help on IRC, I would have a hard time understanding the output of the commands. Likewise, it makes it difficult to report a bug and also to look for other people with the same problem or error message.

On the other side, there is the obvious advantage that using the CLI does not need knowledge of english anymore.

The POSIX system allows both. By default the apps are localized, but you will often need to revert to the "POSIX" or "C" locale.

[axeld]

One compromise would be to accept localizing them, but set the locale to POSIX by default. Not sure if that makes a lot of sense, though :-)

[jua]

Localizing is a good idea as it's more user friendly. The arguments against don't convince me: writing scripts which parse the unstructured text output of a wordy command line tools is usually bad anyway, because it easily breaks when the output changes with an update of the tool. And in the case of remote help you could make the same argument to remove our GUI localization too... In any case, if remote help or script use needs the English output, it should be trivial to override the language setting by setting an environment variable for the command.

[pulkomandy]

If the environment variables do work for this, then yes. I don't know if the locale kit will take them into account, however. I would suggest that we at least make the overriding work, before we engage on localizing CLI apps (or alternatively, we could add "porcelain" output like git, or make more use of hey and the messaging system for scripting).

[jua]

Yes I agree, if overriding doesn't currently work, we should wait with localizing...