I didn't look at other software, but here is my view:
- for long texts, like help, we may have a key by paragraph. This will shorten the use of HTML in the code and allow us to have the same system for both kinds of text.

- If we use short keys, falling back to the key if lang is not found could lead to misunderstanding.
IMO, all texts that are not real sentences (Subject, verb, complement), should not have short keys. Short keys would then reflect a summary of the content, e.g.  "help_config_intro1". I used this one intentionally because we have 2 paragraphs in introduction.

mathiasm wrote:

I didn't look at other software, but here is my view:
- for long texts, like help, we may have a key by paragraph.

If the help is a on a 'per page' basis, why do not use a key per page? (and have only one entry for each whole help page)

tosca wrote:

If the help is a on a 'per page' basis, why do not use a key per page? (and have only one entry for each whole help page)

I think it would be a good way to have the page never translated.

What makes a page easier to translate is the way it is cut. The smaller the string is, the easier it is to translate. If you ask a translator to translate a 3000 words page, I'm afraid the page won't ever be translated. This is one of the main issues ddtddt meets in translation management: getting the common.lang.php translated is quite easy compared to getting the help/synchronize.html page translated.

tosca wrote:

plg wrote:

I think it would be a good way to have the page never translated.

What makes a page easier to translate is the way it is cut. The smaller the string is, the easier it is to translate. If you ask a translator to translate a 3000 words page, I'm afraid the page won't ever be translated. This is one of the main issues ddtddt meets in translation management: getting the common.lang.php translated is quite easy compared to getting the help/synchronize.html page translated.

:lol: I can only speak for myself: I'd rather translate a whole page (it is real text, that makes sense) than short labels or paragraphs.

It's a point of view. But help page is not a story. It gives contextual help for topic on the current page. We need anchor in text to give right help for each context.
I think mastiasm is right : we should (must ?) do one key for each paragph (or sentence or line) for help pages to make life of translator easier. Nobody (except Tosca!!!) wants to translate a whole page !

nicolas wrote:

If I understand your proposition, you want a special language for fallback and you want to keep en_US language. What will be the key for long phrases ? I want to avoid key without meaning to make life of translator easier as possible.

In TL system, translators don't know about the key: they see the english translation in the left column, and write their translation in the right one.

plg wrote:

2) a key that can be used as value (remember that current algorithm is : is the value is not available in current language, display the key)

And the fallback language is english (not the key).

PS: I just mailed the responsible for the french TL team to ask about the translation tool we use for the TL core.

Last edited by tosca (2010-02-26 18:37:49)

i made the really big commit ([Subversion] r5021) and now Piwigo use gettext for localization.

How to help and test :
- install the trunk version
- change language


If you find a word (phrase) not translated, report it.

To make modification available, you have to compile messages.po in messages.mo with :

msgfmt language/$language/LC_MESSAGES/messages.po -o language/$language/LC_MESSAGES/messages.mo

What about local language files? (local.lang.php)