Forum OpenACS Development: Localization questions

Collapse
1: Localization questions
Posted by Chris Davies on 01/27/04 04:03 AM
I started to do the localization on a module I'm working on as a learning experience, and found it to be quite easy, but I came across an issue that perhaps has been dealt with in the past.

In particular, I need to use the message 'Delete' on one of my pages.

It seems that defining the key and message in my own package requires the duplication of translating the same phrase multiple times across multiple packages.

Is there a common repository for 'common' phrases -- or should I create new keys for every phrase, even if it is reused?

For example, in my installation the phrase Delete exists in:

acs-kernel.common_delete
acs-subsite.Delete
faq.Delete
forums.delete
news.Delete

I saw some mention on the translation server that there were a lot of keys consolidated, but, is there an effort to combine keys that contain the same message?

Or, should each package maintain its own set of keys?

Collapse
2: Re: Localization questions (response to 1)
Posted by Joel Aufrecht on 01/27/04 09:50 AM
Whenever possible, please use acs-kernel.common*.  In the example above, all of those packages should probably be modified to use acs-kernel.common_delete.  If you have new phrases that you think should be in acs-kernel.common*, post or file a bug.
thanks
Collapse
4: Re: Localization questions (response to 3)
Posted by Matthias Melcher on 01/28/04 07:24 PM
Chris,

thanks for the compilation of messages that could save
effort of translators or/and programmers. I think, however,
that it is the wrong approach to focus on the mass of
single words. The most laborious work ist not typing
translations for single words, but
- finding the contexts, and
- consolidating terminology.

You and Joel are right that programmers should not simply
create new message keys without consulting a central
repository. This repository, however, should contain some
hint leading to the .adp page or other UI context that
displays the message in question.

Then, the programmer could decide
- if his intended usage matches the terminology of the keys
  already available, or
- if the new terminology diverges and a new key must be
  created (ideally after some more deliberation about
  the usability and consistency of the terminology).

As Anja already warned here,
https://openacs.org/forums/message-view?message_id=135282
much care is needed to merge keys.
I cross-checked your list with our translations, and there
are many differences, although it's also a Germanic language
(so I would suspect there are still more problems with
languages less akin).

Action:
Administrative Actions: concatenated in one word, needing
lower case initial letter;
This action cannot be reversed: transcribed by one Word
("unwiderruflich")
This action will take...: different Word ("Vorgang")
Action in Curriculum: very preliminary due to broken
functionality.

Administer:
sometimes standing not alone (needing upper case) but also
sometimes prefixed by object (needing lower case)

Approved:
used for very different things:
E-Mail Servers ("genehmigt)
member state ("freigeschaltet")
other cases (mostly "freigegeben")

Author:
in more general cases as with filestore, a different word is needed ("Autor") than in more concrete ones as forums and news ("Verfasser").

Confirm:
To confirm: translated as noun (needing upper case)
Different word order (needing upper case) same as with Administer above

Email:
only sometimes used for the email letter itself,
often synonymously used like email address, and
sometimes meaning the action of emailing, both requiring
different (more precise) translation

Error:
compositions like "database error" or "error message" need
single Word ("Fehlermeldung") and therefore sometimes lower
case ("Datenbankfehler").

HTML:
Static (HTML) Data: needs different composition "HTML-Daten"

Name:
very dangerous, see opposite bug description
https://openacs.org/bugtracker/openacs/bug?bug%5fnumber=963

Preview:
incidentally all German occurrences are upper case, but English are different (e.g. faq.preview)

Search:
sometimes used as verb, sometimes used as noun.
Search forums: needs prefix "Foren DURCHsuchen"; if the same were applied to
Search users ("Benutzer durchsuchen") this would mean a
police personal search (Leibesvisitation).
Compositions needing lower case as Administer or Error above

Status:
Just lower case problems due to word composition as above.

Title:
critical, see separate discussion
https://openacs.org/forums/message-view?message_id=135956

Collapse
6: Re: Localization questions (response to 1)
Posted by Joel Aufrecht on 01/28/04 09:22 PM
Perhaps some of the professional translators could suggest keys which are safe to be merged.  How about yes and no?  The advantage I'm seeking here is a reduction in the total number of keys that must be translated in a new language.  However, most of the potentially reusable words are less reusable than assumed, then perhaps this particular effort is counter-productive and we should leave the keys as they are instead of diverting translators' attention for small savings.
Collapse
5: Re: Localization questions (response to 1)
Posted by Chris Davies on 01/28/04 10:15 PM
ok, I think I understand.

I'll create my own keys and leave it up to someone more educated to make the decision to consolidate.

Collapse
7: Re: Localization questions (response to 5)
Posted by Anja Wicht on 01/29/04 07:04 PM
Hi,

First of all, thank you Matthias for your thorough answer which I think illustrates the problem of merging message keys very convincingly. By the way, I hope no one feels offended. Please understand that after spending so much time (and nerves) on struggling with the various problems presented by split messages, we're keen to create some awareness among programmers and to help make translation easier and more efficient in the future.

In general, it's important to leave the messages whole as far as possible (even if it's several sentences that belong together).

Concerning the use/creation of common message keys (from whole messages), there's unfortunately no golden rule. The more standardized the message is, the more likely it works. That's the case with Add, Apply, Cancel, Continue, Delete, Discard, Edit, Finish, Go, Help, Log in, OK, Register, Reset, Save, Stop, Update or phrases like "This may take a while, please be patient." But it is not easy to decide without knowing the target language, and as we've seen, even Search and Approve are problematic. The same is true for Yes and No; when they occur together (as options), common keys are ok. In other cases, translations for No vary (in German Nein or Kein/Keine/Keiner) depending on the context. So if in doubt, please create extra keys, that's the safe way.

Anja
Collapse
8: Re: Localization questions (response to 1)
Posted by Chris Davies on 01/29/04 10:06 PM
no offense taken here.

Being educated in the US Public Schools, I am monolingual.  As a result, I am handicapped when it comes to internationalization.

My initial thoughts were, I'm using the phrase Email Address. Certainly someone must have already translated that phrase, so, do I force someone to translate it one more time or are there common phrases.  Similarly the words Yes, No, Delete and a few others came up -- and were in a number of different packages.  I didn't expect basic words to have different meanings.

With the explanation provided, it makes perfect sense.