[Locale Kit] localize /src/system/libroot/posix/string/strerror.c

[diver]

There are a lot of untranslated errors defined in:
​http://cgit.haiku-os.org/haiku/tree/src/system/libroot/posix/string/strerror.c

[diver]

nielx, could you look into it?

[pulkomandy]

We are undecided about this because the general approach so far was to not localize command line applications and system messages. In particular, localized strerror would be annoying in bugreports. If we do this, we need to print the error value as well in the message so that bugreports can be understood by anyone no matter their language.

[diver]

Ah, yes. However, these errors also appear in GUI apps. Is it possible to distinguish between those and continue using untranslated strings in cli apps?

[nielx]

What complicates matters here is that the screenshot on ticket 15528 shows that this is not limited to command line applications.

Even without making a decision on whether or not to localize command line apps, and how to handle system messages, I argue that Tracker's example is just bad.

IMO in the particular case of #15528, we could figure out what the point of the error is. Is it an expected error case that is properly handled by the code? In that case we don't need the low-level error description. Is it an unexpected error/unhandled error? I would argue that instead of printing the description of the error, we print the error code. That leaves valuable information for debugging, but it removes the untranslated parts. The error code might be a bit on the geeky/user unfriendly side, but that would be acceptable for an unexpected handled error.

[pulkomandy]

These error messages are just a debugging help for developers. So yes, I would go with making them more "geeky", but still friendly. Showing "B_NO_MEMORY", etc would work.

However this would also be less nice than what we have now, at least for english users. A compromise would be "Out of memory (B_NO_MEMORY)" with both a translatable string and the non-translatable error code/name. This way we have info for both the user and the developer.

[nielx]

Replying to pulkomandy:

These error messages are just a debugging help for developers. So yes, I would go with making them more "geeky", but still friendly. Showing "B_NO_MEMORY", etc would work.

Is there an existing function that transcribes error codes to their identifiers?

However this would also be less nice than what we have now, at least for english users. A compromise would be "Out of memory (B_NO_MEMORY)" with both a translatable string and the non-translatable error code/name. This way we have info for both the user and the developer.

It seems that glibc opts for ​char *strerror_l(int errnum, locale_t locale) with an explicit locale parameter. Implementing this in libroot does mean we have to set up some sort of locale system in libroot, which sounds like overkill to me.

Alternatively I can imagine that we have a function in libbe that provides localized errors as part of the support kit (strerror_i18n() or error_description(). Applications that are explicitly localized, and that do want to use error descriptions as part of their user interactions, can opt to use this as an alternative.

[pulkomandy]

Well, you don't have to do the translation in strerror. You can return an english string, and the app can call B_TRANSLATE_SYSTEM_CATALOG on it if it wishes so. We then only need to collect the strings and put them in the system catalog. You can see how the system catalog is used in BColorControl, for example (and a few other places but I remember of this one in particular).

And no, there is no translation to identifiers currently, because that's what strerror is supposed to do. But it went with something more readable than the identifiers, and then people started using these as user-facing messages.