To Zanix, and and French roster 'admin' user (that reads English )

I'm have looked at something strange this morning that 'bugs' me now for sometime.

Go overhere : http://www.papy-team.fr/roster/index.php?p=rostercp (read on for info) and try to set the roster language in "Main Settings" to French.
Selecting frFR in the select box will, but a quick look will confirm that if the setting was any different from frFR before, the 'locale' string won't be written to roster_config table.

Somehow, in config.lib.php, on line 476, the code decides that the value didn't changed.
The var name $settingName is correctly formed to 'locale' and $settingValue is 'frFR'.

Even if (should be) << $config[$settingName] >> is set to i.e. enUS, and I select 'frFR', the if statement isn't true.
Meaning, $config[$settingName] (is $config['locale'] ! ) is always 'frFR', even if selected a value in the drop down box that was something different (and thus, the value in the database config tabe ) before.

Needless to say, I'm using a French browser.
This means I can't set the langauge on the cp page to frFR, it won't "stick" because never written to the table.
(Up until now, I considered as a minor, tiny, annoying issue - I hopped phpMyAdmin directly after a re-install to have things my way).

After some checking I discovered this on line 65 in lib/locale.php:

Code: Select all

      if( isset($_SESSION['locale']) && $_SESSION['locale'] != '' )
      {
         $roster->config['locale'] = $_SESSION['locale'];
      }

So, $config['locale'] has already being set to 'frFR' in my case, even if the value in the database table 'roster_config' is different - and thus should be over written.
These statement are present in locale.php, included directly by seettings.php, and are part of the constructor of the class roster_locale.

This means that a changing to 'frFR' in the drop down box will not be having any effect, the change won't be written to the config table because the code concludes that nothing changed !

The nasty part :
I can't propose a correct solution for this.
-> Is the language select box not needed on the admin 'cp' page ?
or
-> Shouldn't there only be one, the one in the top box, who is public ?
-> The code in processData() chould contain code to override the $roster->config['locale']... case or even writing ALL the config vars to the table, no mather what..
-> if( isset($_SESSION['locale']) && $_SESSION['locale'] != '' ) should be disabled, so that roster->config['locale'] is set the table choix, instaed of the browser choix ?
-> if( isset($_SESSION['locale']) && $_SESSION['locale'] != '' ), if set, should set roster->locale directly (which I tried, and seems succesfull)

Anyway, enough info to get the point.

I understand that you didn't saw this point that easily, you're working with the default setup of the roster.
In theory, you could switch your dev roster to another language, and then try to switch back again - you should be confronted with the problem I described here.

Btw : don't think that this is a typical frFR thing, but if needed, PM and I PM you my roster password back, so you can fool around with roster to try for yourself.

I know about the bug, but I thought only the beta debug-on hack was affected. I didn't know locale selection works like this.

There is a possible fix that involves shifting some code around. I'll add it to my todo.

Fixed SVN [1428]

One question with locales.. its necessary load EVERY time the 4 language translations ?
If you use 1 .. because need load 4 ?
If I'm using english .. because need load on php french,german and spanish ?
If you are using french .. i can suppose load english (the base file) and french .. but german or spanish ?
If the addon only use $roster->locale->act because need load ALL files ?
Can be these files load ALL only by demand from the plugin ?
On debug phase .. well its better load all files, but on final ?

Yes, in a Roster install with multiple locales uploaded it is very necessary
So we coded the locale system to load all official locales "localization/language.php" so they are available at all times

The main addon affected by this, AFAIK, is character info. It uses the locale the active character was uploaded in rather than the main one for language consistency. Fully delocalizing the CP data is, unfortunately, not feasible.

Well then make a function or variable like:
LOAD_ALL_LANGUAGES = ON
or load_locale->"XXX"

And make its accessible by addons ..

Then you can active or not when you need... reading/processing 4 languages .. or 1 I think in "loaded" systems will be a great difference of load/process php time.

Only its need it on addons that get information from

Hypothetical situation :
You have a Spanish roster
And, oh dear, You Guilded a French player (bas luck for you, you better speak French then ;-) ).
Well, of course, this guys plays in a localized French WoW version.
So, his items are exported by CP also in French,
… and thrown in your Spanish Roster.
Now, you decide to show his bags.
The tooltips will be French, and have to be parsed with the help of ….. French localized words !!
This will be know only the very moment the frFR localized items start to pop from the database.

What to: Say “oops” – restart the entire page construction; include the French set while we’re at it?
Or
Defining a 3 small Boolean variable which indicates: $FrechLangPresent, $SpanishLangPresent, $GermanLangPresent ?

Honestly, I don’t think that reading in memory arrays several Kbytes of strings (a rather simple var type for the web/php server) really doesn’t bring down the global system performances.
More can be won by looking carefully at all these SQL calls – most of them can be optimized (and will become complete unreadable by humans afterwards ;-) ).
True is, most webhost don’t count SQL server performances, only there webserver.

Another example: Take Joomla, as a CMS, or e107. These two are known as rather fast in the CMS world, yet these projects are several times bigger as the WowRoster V2 project – no one is complaining here ^^

Roster 2.0 actually uses less processing time than 1.7.3
We have made quite a few SQL optimizations and 2.0 doesn't scan the addons folder on every page load

We have also reduced the amount of SQL queries on many pages, the character info module went from 140+ SQL queries in 1.7.3 to 18 in 2.0

If you want to test how much time loading all the locale files takes
Open localization/languages.php and comment out any locales that you do not want to load

Code: Select all

$roster->multilanguages[] = 'deDE';
$roster->multilanguages[] = 'enUS';
$roster->multilanguages[] = 'esES';
$roster->multilanguages[] = 'frFR';

I bet the processing time isn't going to be much different

EDIT:
What might really slow down 2.0 is the debug and the SQL window
We backtrace every SQL query when the window is open and that causes a bit of slowdown
When 2.0 goes final, this window and debug will be off by default

Delocalization:

At moment any person can upload with his personal "locale" and roster known these locale and used it.

Well can be a function to "translate" all terms to the locale of roster?

Example I'm using esES locale on my roster, I have only a person that play in german, if the locale archive have all translation from english to german and english to spanish.. because can query a german word and get the same word in spanish ?

$roster->locale->wordings['deDE'][$term] >>> $roster->locale->wordings['esES'][$term]

$roster->locale->wordings['deDE']['Blacksmithing'] = 'Schmiedekunst'
$roster->locale->wordings['esES']['Blacksmithing'] = 'Herrería'

If i have the word "Schmiedekunst" i can search for it and get the english definition of "Blacksmithing"... and later use Blacksmithing to get "Herrería"

At moment, these function are using "arrays" with again translations .. but if the translations are allready on the files!! because can create "virtually" ? without using locale files.

Code: Select all

$lang['class_to_en'] = array(
   'Druida' => 'Druid',
   'Cazador' => 'Hunter',
   'Mago' => 'Mage',
   'Paladín' => 'Paladin',
   'Sacerdote' => 'Priest',
   'Pícaro' => 'Rogue',
   'Chamán' => 'Shaman',
   'Brujo' => 'Warlock',
   'Guerrero' => 'Warrior'
);

its not the same ?

Code: Select all

$lang['class_to_en'] = array(
   $roster->locale->wordings['esES']['Druid'] => $roster->locale->wordings['enUS']['Druid'],
   $roster->locale->wordings['esES']['Hunter'] => $roster->locale->wordings['enUS']['Hunter'],
   $roster->locale->wordings['esES']['Mage'] => $roster->locale->wordings['enUS']['Mage'],
   $roster->locale->wordings['esES']['Paladin'] => $roster->locale->wordings['enUS']['Paladin'],
   $roster->locale->wordings['esES']['Priest'] => $roster->locale->wordings['enUS']['Priest'],
   $roster->locale->wordings['esES']['Rogue'] => $roster->locale->wordings['enUS']['Rogue'],
   $roster->locale->wordings['esES']['Shaman'] => $roster->locale->wordings['enUS']['Shaman'],
   $roster->locale->wordings['esES']['Warlock'] => $roster->locale->wordings['enUS']['Warlock'],
   $roster->locale->wordings['esES']['Warrior'] => $roster->locale->wordings['enUS']['Warrior']
);

Because can't create a "virtual" array translation .. geting a word in a specific language and getting his "translation" to another ?

All members data and most players data is available in english, or can be feasibly translated. We don't do it yet, but we could.

However, we are only now really getting item parsing down. To translate items, we'd have to parse and delocalize them at upload. Making that change for 2.0 is not doable, unless you think shoving it back another month or two is acceptable.

PleegWat wrote:.... unless you think shoving it back another month or two is acceptable.

I think Subxero is gona learn this german guy really fast the Spansih language - you got 2 months also