Forums

Unfortunately no one can be told what FluxBB is - you have to see it for yourself.

You are not logged in.

#51 2011-01-11 10:48:31

jojaba
Member
From: Obersoultzbach, Elsaß, France
Registered: 2009-12-04
Posts: 473
Website

Re: 2.0: Language packs etc. (RFC)

Well, I didn't read all that discussion.
But I understood that the theme is the translation system upgrade.
I'm used to "play" with a really simple CMS called Plume CMS. In this cms, the translation files are called like this :

installation.lang

Here's what the contain looks like:

# -*- coding: utf-8 -*-
# Commentaires

;There is an error with your login or your password.
Il y a une erreur dans votre identifiant ou votre mot de passe.

;Login:
Identifiant :

;Password:
Mot de passe :

;Ok
Ok

;You need to accept the cookies to access the manager.
Vous devez accepter les cookies pour accéder au Manager.

...

And the translkation is made by a function called __() :

<?php echo __('Login:') ?>

It's really a good way to ease the work of the translators, because the strings that have to be translated are in the translated files.

If you are interested in this translation system go to the Plume CMS site and see the source code :
http://pxsystem.svn.sourceforge.net/vie … cms/trunk/
The translation class: http://pxsystem.svn.sourceforge.net/vie … iew=markup wink


Localize Mozilla extensions on BabelZilla

Offline

#52 2011-01-11 10:51:48

Reines
Administrator
From: Scotland
Registered: 2008-05-11
Posts: 3,197
Website

Re: 2.0: Language packs etc. (RFC)

jojaba wrote:

It's really a good way to ease the work of the translators, because the strings that have to be translated are in the translated files.

This is what Franz was suggesting at one point - but as I said earlier, if you use the English translation as the key (as in your example), any change in the English language pack and all others will need their keys updated. This means a single spelling mistake or grammer fix would break every single language pack, which in my opinion is not acceptable.

Offline

#53 2011-01-11 13:03:34

jojaba
Member
From: Obersoultzbach, Elsaß, France
Registered: 2009-12-04
Posts: 473
Website

Re: 2.0: Language packs etc. (RFC)

Reines wrote:
jojaba wrote:

It's really a good way to ease the work of the translators, because the strings that have to be translated are in the translated files.

This is what Franz was suggesting at one point - but as I said earlier, if you use the English translation as the key (as in your example), any change in the English language pack and all others will need their keys updated. This means a single spelling mistake or grammer fix would break every single language pack, which in my opinion is not acceptable.

That's right but on the other hand, if no translation of a string is provided (for example if you update the english original string), in the Plume CMS translation system, the english string is displayed, so no error will occur. As you said, a translation file should be a .txt (or storing) file, not a php file, it's aim is only to store datas. wink


Localize Mozilla extensions on BabelZilla

Offline

#54 2011-01-11 13:10:20

Reines
Administrator
From: Scotland
Registered: 2008-05-11
Posts: 3,197
Website

Re: 2.0: Language packs etc. (RFC)

jojaba wrote:

That's right but on the other hand, if no translation of a string is provided (for example if you update the english original string), in the Plume CMS translation system, the english string is displayed, so no error will occur. As you said, a translation file should be a .txt (or storing) file, not a php file, it's aim is only to store datas. wink

Maybe not a syntax error, but I would still call messages in a foreign language pack suddenly turning to English an error. If the reason you like this is it's easier to see what you are translating from there is nothing stopping you/us putting the English phrase as a comment above the translation if an XML format was used. For example:

<!-- There is an error with your login or your password. -->
<entry key="login error">Il y a une erreur dans votre identifiant ou votre mot de passe.</entry>

<!-- Login: -->
<entry key="login label">Identifiant&nbsp;:</entry>

Offline

#55 2011-01-11 13:40:17

Smartys
Former Developer
Registered: 2008-04-27
Posts: 3,139
Website

Re: 2.0: Language packs etc. (RFC)

Why do we have to re-invent the wheel? hmm

And here's my two cents on this key discussion: English keys promote a better experience for everyone overall. Don't believe me? Lets think about it:

Our current system uses PHP arrays and unique keys. If a language pack is missing a key, content is not displayed. If the value of a key in the English language pack is updated, translators do not necessarily update the corresponding translation.

Now, consider a system using gettext and the English language text as keys. If the language pack is missing a key, English text is displayed: I'd argue that's superior to not displaying anything at all. Furthermore, if the English text changes, translators are forced to acknowledge the change and update their language packs (because if they don't, they'll start displaying English text): at the very least, that makes sure any language changes are handled properly.

Last edited by Smartys (2011-01-11 13:40:29)

Offline

#56 2011-01-11 14:27:43

Reines
Administrator
From: Scotland
Registered: 2008-05-11
Posts: 3,197
Website

Re: 2.0: Language packs etc. (RFC)

Smartys wrote:

If the language pack is missing a key, English text is displayed: I'd argue that's superior to not displaying anything at all. Furthermore, if the English text changes, translators are forced to acknowledge the change and update their language packs

Actually when you think of it that way, that does make sense. I was worrying about updating existing translations, but not thinking of adding new translations.

Offline

#57 2011-01-11 15:32:10

artoodetoo
Member
From: Far-Far-Away
Registered: 2008-05-11
Posts: 219

Re: 2.0: Language packs etc. (RFC)

May I concrete the target?

Really, there are no real plural- or mixed-language forums. They are English OR Russian OR Erench, etc. So, may be "english without localization files" is not as good as topic starter suppose. May be it is very slightly accelerate process of coding. Where is the profit for users?

Next, about templating, OOP and efficiency. The $lang_*[...] is probably the fastest way to out something. When we'll have some "template language" we'll have ability to translate designer view to any PHP code. Let it be good looking on the template and fast on the run-time . FluxLang::t() is neither good looking, nor fast.


I'm not a fan of FluxBB way anymore.

Offline

#58 2011-01-11 15:50:51

Freeman
Member
From: St. Petersburg, Russia
Registered: 2010-10-23
Posts: 13
Website

Re: 2.0: Language packs etc. (RFC)

I agree with artoodetoo.

For example, Miranda IM uses English strings for keys, and the problem with English mistakes exists for it. It's one of the bad design practices, because makes one languagle more preferable than others. I'm traiting internationality as language independence, not English-basement.

Offline

#59 2011-01-11 16:13:24

Reines
Administrator
From: Scotland
Registered: 2008-05-11
Posts: 3,197
Website

Re: 2.0: Language packs etc. (RFC)

artoodetoo wrote:

Where is the profit for users?

Really what it comes down to is:

Using a neutral key like at the moment:

  • Updating a language pack has no effect on another language pack.

  • Any missing entry gets left blank or gives an error message.

Using full English strings as suggested:

  • Updating the English strings will require other language packs to be updated.

  • Any missing entry gets replaced with the English version.

If the change was simply fixing a typo or grammar in the English pack, obviously that breaking other packs is bad. However if it was re-phrasing or adding a string, and hence other packs should be updated to match, it is good - as Smartys said, presumably a string appearing in English is preferable to being left blank, getting a syntax error, or simply having an out-of-date and wrong translation. Both systems have advantages/disadvantages here for board admins.

I only speak English so have never done any language pack development, but I would imagine having the English version visible to translate from helps. Really this can be done for both though - either as the key or simply a comment.

As a developer, it would be much easier to simply provide English strings in the code, and FluxBB can automatically perform the translation if/when required.

Offline

#60 2011-01-11 17:50:51

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,545
Website

Re: 2.0: Language packs etc. (RFC)

artoodetoo wrote:

May be it is very slightly accelerate process of coding. Where is the profit for users?

There, you named it. We develop faster, users get their releases faster (plus you can enjoy this when developing extensions).
Granted, the gain might not be huge in this particular case, but that is generally one of the reasons why refactoring like this is taken into consideration.

artoodetoo wrote:

Next, about templating, OOP and efficiency. The $lang_*[...] is probably the fastest way to out something. When we'll have some "template language" we'll have ability to translate designer view to any PHP code. Let it be good looking on the template and fast on the run-time . FluxLang::t() is neither good looking, nor fast.

General question: Any reason not to just "merge" the proposed FluxLang and the template class? Then we wouldn't really have above problem, it might even be faster because we wouldn't have to mess with globals, passing language variables etc.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#61 2011-01-11 18:08:11

Reines
Administrator
From: Scotland
Registered: 2008-05-11
Posts: 3,197
Website

Re: 2.0: Language packs etc. (RFC)

Franz wrote:

General question: Any reason not to just "merge" the proposed FluxLang and the template class? Then we wouldn't really have above problem, it might even be faster because we wouldn't have to mess with globals, passing language variables etc.

It depends how we go about splitting FluxBB into API <-> frontend, and partially also if we decide to use key based or English language based translations.

At the weekend I made a start of splitting a few things apart just to see how easy it would be, and certain things are easy (for example $fluxbb->fetch_bans(), $fluxbb->delete_post(...) etc.), but others (for example $fluxbb->create_post(...)) are harder because of error checking. If an error is encountered inside the API how should it be handled? As I see it, there are a few options:

  • Return the translated error. This would require the language class shared by both the API and frontend, which is messy and not sure.

  • Return a status code - the frontend would then check the return code and fetch the appropriate error, and handle translation. This seems a bit long winded to me.

  • Return an untranslated string, either the key or english translation depending on how we go about handling translations (this is actually an argument for using full English strings as keys, then the API output would still make sense if used somewhere without the translation layer, instead of outputting crap like "bbcode error 1".

Anyway my point is, yes as long as we don't want to try share the language class across both the frontend and API (which would be a horrible way to do it) I don't see any reason it couldn't be included in the template engine.
Though I don't think merge is the right word - that implies we would be ramming all the code in 1 class, which would not be nice. The overhead added by doing things properly with OOP is minimal - if anyone thinks the difference in speed between $lang['bla'] and $lang->t('bla') is worth worrying about then you are really trying to optimise the wrong thing.

Offline

#62 2011-01-11 21:13:18

jojaba
Member
From: Obersoultzbach, Elsaß, France
Registered: 2009-12-04
Posts: 473
Website

Re: 2.0: Language packs etc. (RFC)

Just to have here a resource that could be a good inspiration: The Zend Framework translate tool
You can read there the pro and contras about the different translation systems...
This resource is provided in several languages : fr, de, ru, zn, ...


Localize Mozilla extensions on BabelZilla

Offline

#63 2011-01-11 21:59:26

Franz
Lead developer
From: Germany
Registered: 2008-05-13
Posts: 6,545
Website

Re: 2.0: Language packs etc. (RFC)

By the way, I am not sure that we should think that much about possible spelling mistakes, for two reasons:
- They happen very rarely, and we can do multiple checks and re-read everything before we release code
- The translation center will make handling these cases pretty easy.


fluxbb.de | develoPHP

"As code is more often read than written it's really important to write clean code."

Offline

#64 2011-01-16 07:51:01

artoodetoo
Member
From: Far-Far-Away
Registered: 2008-05-11
Posts: 219

Re: 2.0: Language packs etc. (RFC)

Franz wrote:
artoodetoo wrote:

May be it is very slightly accelerate process of coding. Where is the profit for users?

There, you named it. We develop faster, users get their releases faster (plus you can enjoy this when developing extensions).
Granted, the gain might not be huge in this particular case, but that is generally one of the reasons why refactoring like this is taken into consideration.

Production process is continuous. Perhaps, users will get first release a bit faster, but any mistake or incompletenes in "native english" pattern leads a big troubles for next release. It is hard to change full phrase because of dependent translations.

Franz wrote:
artoodetoo wrote:

Next, about templating, OOP and efficiency. The $lang_*[...] is probably the fastest way to out something. When we'll have some "template language" we'll have ability to translate designer view to any PHP code. Let it be good looking on the template and fast on the run-time . FluxLang::t() is neither good looking, nor fast.

General question: Any reason not to just "merge" the proposed FluxLang and the template class? Then we wouldn't really have above problem, it might even be faster because we wouldn't have to mess with globals, passing language variables etc.

Who votes for globals? We can retrieve $lang variable just in place from Registry or some Factory. Make once, use often.

In perfect world any translation should be used in the View only. Imagine some pseudo template:

{!uses lang_common, lang_forum /* --> $lang_common = Lang::cached_load('common'), ... */}

<div>
  <h2>{$lang_common['Forum']}</h2>
  {!for $topic in $topics}
  <div>{$lang_forum['Topic']}: {$topic['subject']}</div>
  {!/for}
</div>

That way we can both: save present translations and kill globals.


I'm not a fan of FluxBB way anymore.

Offline

#65 2011-01-16 08:55:11

artoodetoo
Member
From: Far-Far-Away
Registered: 2008-05-11
Posts: 219

Re: 2.0: Language packs etc. (RFC)

Also, I found interesting topic Editing text strings. kwilson and Otomatic investigate how to cutomize some phrases but keep language file as is ('cause of future updates).
It'll be good to place such "translation exceptions" in core.


I'm not a fan of FluxBB way anymore.

Offline

Board footer

Powered by FluxBB