Opened 9 years ago

Last modified 3 days ago

#7576 assigned bug

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

Reported by: diver Owned by: pulkomandy
Priority: normal Milestone: R1.1
Component: System/libroot.so Version: R1/Development
Keywords: localization Cc: nielx
Blocked By: Blocking: #15528
Platform: All

Description (last modified by diver)

Change History (13)

comment:1 by waddlesplash, 6 years ago

Component: Kits/Locale KitSystem/libroot.so
Owner: changed from pulkomandy to axeld

comment:2 by diver, 4 years ago

Description: modified (diff)
Owner: changed from axeld to pulkomandy
Status: newassigned

comment:3 by diver, 10 months ago

Blocking: 15528 added

comment:4 by diver, 5 months ago

nielx, could you look into it?

comment:5 by diver, 5 months ago

Cc: nielx added

comment:6 by pulkomandy, 5 months ago

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.

comment:7 by diver, 5 months ago

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?

comment:8 by nielx, 5 months ago

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.

comment:9 by pulkomandy, 5 months ago

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.

in reply to:  9 comment:10 by nielx, 5 months ago

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.

comment:11 by pulkomandy, 5 months ago

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.

comment:12 by diver, 3 months ago

Keywords: localization added

comment:13 by pulkomandy, 3 days ago

Milestone: R1R1.1
Note: See TracTickets for help on using tickets.