[haiku] Re: Haiku's localization vocabulary guidelines
- From: PulkoMandy <pulkomandy@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Thu, 23 Jul 2009 23:40:12 +0200
2009/7/23 Jonas Sundström <jonas@xxxxxxxxxxx>:
> 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.
Yes, but it would made working on haiku from various OS (linux, osX,
and beos or derivatives) quite complex. And also prevent the use of
any regular text editor.
>
>> 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.
>
All the catalogs can be embedded as resources or as attributes, or be
stored as plain files in various places (along with the executable, in
a system-wide directory, or in an user-specific directory). But, as
the locale kit is language-neutral, there is no default catalog. If no
language is selected, or if the selected language is not available for
one app, then the fallback is to take the strings inside the
sourcecode. The locale kit allows you to select an ordered list of
your prefered languages, so this shouldn't ever happen if you set it
up right.
>> 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
>
The idea is to actually have two level of translation, one for the
common "guidelined" strings using for example this kind of constants,
and the other one for regular strings. I think the "revert" button you
find in all of haiku's preflet will always use the same translation in
any language, so it makes sense to have it at this global level. If
someone ever make an app using the word "Revert" with another
semantic, he can switch to the regular system, using something like
TR_CMT("Revert","Beware! in EXOTIC_LANG this one does not translate
the same way as LOCALIZED_REVERT_BUTTON"), maybe using a more precise
comment saying why it is different.
> 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.
I don't think the translation can be made right on the first time
without any dev-translator collaboration, as the dev can't figure the
string is used in two different contexts and can't mark it as such.
What should we do ? Use the sourcecode filename and line number to
ensure each string has a unique ID ? Meaning the translator is left
with a file holding dozens of lines with the same string over and over
again, with no idea where each 'OK' will land, and needing to enter a
different translation for each of them to identify where it is used ?
I think communicating with the developper will help everyone. User get
involved in development, which is good even for closed-source apps (i
wrote some in the past and got an incredibly low level of feedback),
Devs, being made aware of the issue, can think more on the words they
used and maybe chose different words in their own language, because it
makes the program easier to understand. Having the same word for two
different things is bad. Of course, there are annoying cases like Edit
> Édition or Éditer in French. Damn french people :D. But no system is
perfect anyway :)
>
> /Jonas.
--
Adrien Destugues / PulkoMandy
Elève ingénieur ENSSAT EII1- www.enssat.fr
GSoC student for Haiku - http://haiku-os.org
GrafX2 project team - http://code.google.com/p/grafx2
Other related posts:
