Multi-Language Support

[GoogleCodeExporter]

I believe you already thought about support for international languages?
What do think about it? 

(teryaki1963 in issue #134, copied here to separate issues)

Original issue reported on code.google.com by crazy4ch...@gmail.com on 7 Nov 2012 at 1:31

[GoogleCodeExporter]

Yes, of course this seems to be a good idea. Here again we'll have to think 
about how we handle this in respect to our single-file approach. We could of 
course put all languages in the single file, but handling languages as 
additional optional files would be a better way I'd say.

Original comment by crazy4ch...@gmail.com on 7 Nov 2012 at 1:32

[GoogleCodeExporter]

My opinion is to only leave the english language in this file. If anyone needs 
additional language he must change his config part and add the language file 
same way as themes:

$language = 'en'; // this is default language. If you want to change it, save 
the language file in same folder of phpliteadmin or in folder "languages"

if($language != 'en' && file_exits($language.'.php')){
   include($language.'.php');
}
else{
   $lang = array(
       'warn1' => 'There was a problem setting up your database',
       'warn2' => 'An attempt will be made to find out what\'s going on so you can fix the problem more easily.',
       'msg1'  => 'Please file an issue report at http://phpliteadmin.googlecode.com'
}

If you think this is a good solution, please let me know, and i'll begin 
working on it!

Original comment by teryaki1...@googlemail.com on 7 Nov 2012 at 3:55

[GoogleCodeExporter]

Yes, I think that's a good solution. But I'd do it slightly differently:

$language = 'en';

// always set the English texts
$lang = array(
  // English texts like you wrote it
);
// now overwrite with these texts that are in the language-file
if($language != 'en' && file_exits($language.'.php')){
   include($language.'.php');
}

So the file de.php would look like:
$lang['warn1']='Es gab ein Problem die Datenbank zu nutzen.';
$lang['warn2']='Es wird versucht herauszufinden was hier passiert, sodass du 
das Problem leichter beheben kannst.';
...

So in case the language-file is incomplete, English texts will show up as a 
fallback solution automatically.

The problem with language-files in my experience is that somebody makes the 
translation. Then you add a new text in the new version and mail the translator 
about it, but he is gone and doesn't reply. So it's good if you can just use 
incomplete language-files as well.

When defining the array-keys for the texts, it might be good to structure them 
a bit like 'table_column_delete_confirmation' where possible.

In my other open Source project CrazyStat I used constants for language-texts. 
This has some advantages and disadvantages:
+ no need for global $lang; everywhere
+ L_MY_LANG is shorter than $lang['my_lang']
+ perhaps a bit more efficient
- are constant ;-) so you cannot use a simple overwrite-solution as described 
above to implement a fallback-solution. You would need to do 
if(!defined('L_MY_LANG)) define('L_MY_LANG','value'); everywhere in the lang 
file to do this.

Another option is to use a lookup-function or method like lang('my_lang'). In 
there you could use arrays or anything you like.
+ functions are global
+ the function calls spread over the application remain stable even if you 
change the way you store the data
- function-call adds unnecessary overhead

In the end it's a matter of taste I'd say. I guess with a simple and small 
project like phpLiteAdmin I'd choose the array-approach as well for simplicity.

It would be cool if you would implement this. I know this is a lot of work (I 
did the same for CrazyStat) but I guess the number of texts in phpLiteAdmin is 
not _that_ high.

Ah, and I'd propose to use sprintf() for texts that include some values, e.g.

$lang['table_drop_confirmation']='Do you really want to drop table %s?';
sprintf($lang['table_drop_confirmation'], $tablename);

Original comment by crazy4ch...@gmail.com on 7 Nov 2012 at 5:18

[GoogleCodeExporter]

thanks, that helps me further.
i'll begin making an external en.php file than we copy the array. en.php can be 
used as sheet for other translations.

Original comment by teryaki1...@googlemail.com on 8 Nov 2012 at 6:54

[GoogleCodeExporter]

Cool! I could do the German translation but I guess you are German as well, 
right? ;-)
But I could write to the guys who translated CrazyStat and ask them if they 
would like to translate another open source script. For example I guess I could 
motivate my Russian translator... This way we might be able to come up with 
some translations quite fast.

By the way, if anybody reads this who would like to help translate phpLiteAdmin 
into another language, please drop a comment so we can contact you once it's 
time to start translations ;-)

Original comment by crazy4ch...@gmail.com on 8 Nov 2012 at 9:08

[GoogleCodeExporter]

OK, i'm done but i can't edit svn any more?

Original comment by teryaki1...@googlemail.com on 9 Nov 2012 at 6:43

[GoogleCodeExporter]

Hmm... I checked your rights. You should be allowed to commit to svn.
Try:
- svn update
If somebody committed stuff after you updated the last time, you need to 
update. If you and the other guy (probably me because I committed last) 
modified the same file, you need to solve the conflict. Ask in case you need 
help with this.
- svn add en.php
In case you did not add your new file yet. You need to add it to version 
control before you can commit it.
- svn commit

Ask if it still doesn't work.

Original comment by crazy4ch...@gmail.com on 9 Nov 2012 at 6:49

[GoogleCodeExporter]

I don't know how to solve this conflict?
I tried to upload phpliteadmin.php again, but i get unknown server error.
i also chaged file name, i get same error

Original comment by teryaki1...@googlemail.com on 9 Nov 2012 at 7:09

[GoogleCodeExporter]

Seems you succeded! Cool. Amazing how fast you did this. Thanks a lot.

Original comment by crazy4ch...@gmail.com on 9 Nov 2012 at 7:22

• Changed state: Started

[GoogleCodeExporter]

Now it worked suddenly :))
ok please check the changes. Some code im not sure of changing it?

    Cool! I could do the German translation but I guess you are German as well, right? ;-)
Not exactly. I live in germany for a long time. My origin is palestine. So im 
half-german now :)

    Thanks a lot.
No problem

Original comment by teryaki1...@googlemail.com on 9 Nov 2012 at 8:01

[GoogleCodeExporter]

Okay, I'll check your changes tomorrow. In my experience, one can easily 
overlook some texts so I'll also have a look whether it is complete.

So would you like to do the German translation or should I do it? If you are 
from palestine, you might be able to do some other translation? Hebrew maybe?

Original comment by crazy4ch...@gmail.com on 9 Nov 2012 at 8:43

[GoogleCodeExporter]

I think your german is better than mine, maybe i can try arabic but when its 
complete checked.

Original comment by teryaki1...@googlemail.com on 9 Nov 2012 at 10:42

[GoogleCodeExporter]

Okay, I'll do the German translation then.

I am currently checking your changes. One thing I noticed is that you included 
some texts in your language-array that is only debug-information. I'd say 
debug-information does not need to be translated. Most of the debug information 
only really makes sense for the developers and it is not really meant to be 
understandable by ordinary users.

I think I might hardcode those debug-texts again. The point is that we should 
not ask translators to translate stuff that is really unnecessary to translate. 
And in some places it really does not make sense. For example at lots of places 
I added debug info like "variablename = ($variablename)". If variablename would 
be translated here, this would make debugging even harder.

Original comment by crazy4ch...@gmail.com on 10 Nov 2012 at 2:17

[GoogleCodeExporter]

Yah, sorry
thats why i said, i wasn't sure about it, cause i still don't know the code well
I hope its not much work for you :)

Original comment by teryaki1...@googlemail.com on 10 Nov 2012 at 4:05

[GoogleCodeExporter]

No problem. I just checked your changes and committed some adjustments to svn.
I didn't check for completeness yet. I'll do so soon.

You did a good job. Of course the effort of checking your changes is far lower 
than doing this myself. So thanks a lot for your work.

Original comment by crazy4ch...@gmail.com on 10 Nov 2012 at 7:15

[GoogleCodeExporter]

By the way: I did these automated checks (and corrected mistakes if found):

- check whether some language-keys are defined more than once
- check whether all used language-keys are actually defined
- check whether all defined language-keys are actually used

So in regards of these aspects, the current version should now be correct. (I 
did use regex on the source to extract used and set language-keys, imported 
this into a DB and ran the checks using SQL inside the db. Worked pretty smooth 
and spotted some mistakes very efficiently.)

Original comment by crazy4ch...@gmail.com on 10 Nov 2012 at 7:19

[GoogleCodeExporter]

very nice :)
one thing i should mention: 
line 4001: i added class='".$field."_textarea' to let textareas have individual 
class values. This is important, cause every user can change the look of his 
edit area. E.g. for me i added a jquery editor (CLEditor: 
http://premiumsoftware.net/cleditor/) to one of the textraeas in my copy.

Original comment by teryaki1...@googlemail.com on 10 Nov 2012 at 7:56

[GoogleCodeExporter]

Oh, sorry that I removed this. I inserted it again, using htmlencode($field). 
In case the fieldname contains single-quotes, characters <>& or stuff like 
that, the HTML would get broken otherwise.

Original comment by crazy4ch...@gmail.com on 10 Nov 2012 at 9:29

[GoogleCodeExporter]

Okay, I went through the whole code again to check whether some texts are still 
hard-coded. I did not correct this yet, I just added a #todo: $lang everywhere 
I spotted hardcoded-texts. See svn.

If you want to, you can add these texts to the lang-array. I don't have the 
time to do it now, I might be able to in a few days.

Original comment by crazy4ch...@gmail.com on 11 Nov 2012 at 6:00

[GoogleCodeExporter]

Its no problem. 

I did few, but i still have my doubt about some #todo:

1. Are you sure you want to include help in $lang? This might be to much for a 
translator

2. helplink() is using $name as Anchor? like: phpliteadmin.php?help=1#Creating 
a New Database

3. some of #todos are SQL concept like: NOT NULL, Autoincrement etc. i know 
they wont affect the sql statement but they will look strange in other 
languages. I have seen such translation in msn Exel/Access but they look ugly 
(i mean not logic some times) :)))

Original comment by teryaki1...@googlemail.com on 12 Nov 2012 at 12:15

[GoogleCodeExporter]

hey,

thanks for doing some #todos.

1. Hmm. I'd say: We add the possibility to translate this, but translators do 
not have to. If they don't, the English texts will show up automatically as 
fall-back. We should add a comment in the language-file to make this clear.

2. Yes, I noticed that as well. I'd propose giving help-texts ids and using 
these as anchors.
Like:
$lang['help_texts']['create_db']='Text about creating a DB';
phpliteadmin.php?help=1#create_db

What do you think about this approach?

3. Yes, I agree. Therefore I often added question marks like "#todo $lang ??" 
to indicate that I am not sure if it's a good idea to translate this. I guess 
you are right. Just delete the todos in these cases.

Original comment by crazy4ch...@gmail.com on 12 Nov 2012 at 12:24

[GoogleCodeExporter]

ok, i'm almost done, still have 5 #todo?

Help doc added same way in $lang[], even if the anchor is changed it will still 
work

Original comment by teryaki1...@googlemail.com on 13 Nov 2012 at 11:38

[GoogleCodeExporter]

I started with the German translation (see svn).

What is $lang['next_line']? Just a mental note of yours where you stopped 
inserting language constants?

I will finish the German translation soon. I noticed some stuff we need to 
improve regarding language-texts, which I will do as well.

(Somehow Google didn't allow me to send this form with you in CC!? I will try 
to add you again.)

Original comment by crazy4ch...@gmail.com on 25 Jan 2013 at 6:48

[GoogleCodeExporter]

Original comment by crazy4ch...@gmail.com on 25 Jan 2013 at 6:50

[GoogleCodeExporter]

This is almost done, only a few things I'd like to do before 1.9.4 is released:
- finish the last todos that are not yet translated
- look if we need to make some of the language-texts more flexible (i.e. use 
sprintf at some more places)
- push both English and German language file through an automatic spell checker 
to spot potential typos
- perhaps: again check whether there is some unused language definition, some 
undefined language text used or some language text defined more than once

Original comment by crazy4ch...@gmail.com on 11 Mar 2013 at 11:21

• Added labels: Target-1.9.4

[GoogleCodeExporter]

Just finished the last #todos that are not yet in $lang.

Original comment by crazy4ch...@gmail.com on 14 Mar 2013 at 12:43

[GoogleCodeExporter]

Found some more hard-coded texts that need to be in $lang (#todos added, not 
yet done).

Original comment by crazy4ch...@gmail.com on 14 Mar 2013 at 11:43

[GoogleCodeExporter]

If you have a moment, maybe write a couple of lines about this on the wiki. I'm 
adding a link to [Localization] in the configuration page.

Original comment by dreadnaut on 15 Mar 2013 at 4:00

[GoogleCodeExporter]

> If you have a moment, maybe write a couple of lines about this on the wiki. 
I'm 
> adding a link to [Localization] in the configuration page.
Done. It ended up with quite a lot of lines ;-)

I consider this issue as fixed now. Multi-Language support is there, a German 
translation as well. I did some improvements like automatic spell checking and 
now think this is enough for 1.9.4.
There will surely be some things to improve, but I think we should open new 
issues for that.

What remains is to release a German and English localization for download once 
we release 1.9.4 (the English only as a starting point for new translations to 
other languages).

Original comment by crazy4ch...@gmail.com on 18 Mar 2013 at 1:21

• Changed state: Fixed

[GoogleCodeExporter]

Hey

I also translated the lang-file to arabic, but befor i give free there are 3 
points to notice:

(Export with data) not added yet
(yes) is defined but not used
(no) not added

One more thing is, if i wanna get the language file, my browser doesnt 
recognize UTF-8 and i see the german signs like this: "insert" => "Einfügen",
Ok, i can change this manually, but then i need to copy the text und paste in a 
UTF-8 encoded text file. If i dont do this, i have same problem again.
A zip file with the language file in it is maybe easier for the user

Original comment by teryaki1...@googlemail.com on 22 Mar 2013 at 8:33

[GoogleCodeExporter]

Hey

thanks for doing an Arabic translation!

> (Export with data) not added yet
You mean that "Export with data" is hard-coded in the code once? I just fixed 
this with r382 (in the 1.9.5 branch).

> (yes) is defined but not used
You mean it is not used in column_view several times, instead hard-coded? Just 
fixed that in r383 (took me a while to figure out what the problem is here...)

>(no) not added
Just added it in r383.

> A zip file with the language file in it is maybe easier for the user
For users, we offer zip-files in the downloads-section:
https://code.google.com/p/phpliteadmin/downloads/list

Original comment by crazy4ch...@gmail.com on 22 Mar 2013 at 10:06

[GoogleCodeExporter]

Sorry for my bad explanation :)

I uploaded the arabic language file in branch 1.9.5

Original comment by teryaki1...@googlemail.com on 22 Mar 2013 at 11:00

[GoogleCodeExporter]

I uploaded your Arabic language file in the downloads-section.

I did one small change: help_3_x was in German. I replaced this with the 
English text.

Thanks again for your translation!

Original comment by crazy4ch...@gmail.com on 26 Mar 2013 at 5:32

[GoogleCodeExporter]

ohh yah
I'm sorry, i forgot that i used your german copy.
Thx for the fixing :)

Original comment by teryaki1...@googlemail.com on 26 Mar 2013 at 8:24