[haiku] Re: Haiku's localization vocabulary guidelines

PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> You are mostly right. With the current localization
> API it is possible to use arbitrary numbers instead
> of english strings to do the lookup. This has some
> drawbacks, however : first, its not really practical
> for the app developper,

A syntax-aware IDE could be made to display localized
strings in place of their numbers. 

> and second, if there is no translation catalog
> available, everything will be replaced by empty 
> strings, making the app unuseable.

There's no way to embedd a default catalog?

Maybe an ELF section could be invented.
If limiting oneself to Haiku, application 
resources might suffice.

>  The idea is not to get a universal system with a 
> global lookup, there is a separation by application,
> context and comment. The global system will only be
> used for small words you usually find alone on a 
> button. I agree that some of them may use the same
> word in english and need diffreent words in other
> languages, so the idea was to use constants like
> LOCALIZED_CANCEL_BUTTON_TEXT and
> LOCALIZED_CANCEL_MENU_TEXT
 ...
> So, it will always be possible not to use the default
> translation in some case. And I hope the translators
> will hint the developpers when such a case happens.

Does this mean a translator encountering a case where
"Cancel" must be translated differently in two place
must ask the developer to split, e.g. 
LOCALIZED_CANCEL_BUTTON_TEXT into
LOCALIZED_CANCEL_BUTTON_TEXT__EXOTIC_SEMANTIC_FOO
LOCALIZED_CANCEL_BUTTON_TEXT__EXOTIC_SEMANTIC_BAR
and replace occurences in the code with these?

What if along comes another language with overlapping
but slightly differing semantics?

Would that result in the need for:
LOCALIZED_CANCEL_BUTTON_TEXT__EXOTIC_SEMANTIC_FOO
LOCALIZED_CANCEL_BUTTON_TEXT__EXOTIC_SEMANTIC_BAR__X
LOCALIZED_CANCEL_BUTTON_TEXT__EXOTIC_SEMANTIC_BAR__Y

There are so many languages, and even closely related
ones deviate from one another. Seems like a lot of
developer-translator communication to me. Does not 
seem economical. Of course it might help open source
get users pulled into development. ;->

The idea I tried to sketch should hopefully even work
well for post-release community translation of closed 
source software, not necessarily needing any
developer-translator collaboration.

/Jonas.

Other related posts: