Opened 9 years ago

Last modified 2 years ago

#7167 reopened enhancement

A stxtinfo localization

Reported by: Karvjorm Owned by: pulkomandy
Priority: normal Milestone: Unscheduled
Component: Applications/Command Line Tools Version:
Keywords: stxtinfo localization patch Cc: Karvjorm
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

Here is a stxtinfo localization patch.

Attachments (1)

stxtinfo-localization.patch (17.0 KB ) - added by Karvjorm 9 years ago.
A stxtinfo localization patch

Download all attachments as: .zip

Change History (14)

by Karvjorm, 9 years ago

Attachment: stxtinfo-localization.patch added

A stxtinfo localization patch

comment:1 by Karvjorm, 9 years ago

Has a Patch: set

comment:2 by anevilyak, 8 years ago

Owner: changed from nobody to pulkomandy
Status: newassigned
Version: R1/alpha2R1/Development

comment:3 by pulkomandy, 8 years ago

Resolution: invalid
Status: assignedclosed

We don't localize CLI applications.

comment:4 by pulkomandy, 8 years ago

Resolution: invalid
Status: closedreopened

comment:5 by Barrett, 4 years ago

Milestone: R1Unscheduled
Version: R1/Development

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

comment:6 by Karvjorm, 4 years ago

Many Linux CLI apps are localized.

comment:7 by Barrett, 4 years ago

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.

comment:8 by pulkomandy, 4 years ago

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.

comment:9 by axeld, 4 years ago

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 :-)

comment:10 by jua, 4 years ago

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.

comment:11 by pulkomandy, 4 years ago

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).

comment:12 by jua, 4 years ago

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

comment:13 by pulkomandy, 2 years ago

Component: - GeneralApplications/Command Line Tools
Note: See TracTickets for help on using tickets.