Multi-Language Support

[Christopher Kramer]

Originally reported on Google Code with ID 135

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

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

Reported by crazy4chrissi on 2012-11-07 13:31:42

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-07 13:32:04

[Former user]

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!

Reported by teryaki1963 on 2012-11-07 15:55:45

[Christopher Kramer]

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);

Reported by crazy4chrissi on 2012-11-07 17:18:24

[Former user]

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.

Reported by teryaki1963 on 2012-11-08 06:54:33

[Christopher Kramer]

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 ;-)

Reported by crazy4chrissi on 2012-11-08 21:08:08

[Former user]

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

Reported by teryaki1963 on 2012-11-09 18:43:41

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-09 18:49:29

[Former user]

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

Reported by teryaki1963 on 2012-11-09 19:09:04

[Christopher Kramer]

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

Reported by crazy4chrissi on 2012-11-09 19:22:17 - Status changed: Started

[Former user]

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

Reported by teryaki1963 on 2012-11-09 20:01:57

[Christopher Kramer]

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?

Reported by crazy4chrissi on 2012-11-09 20:43:35

[Former user]

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

Reported by teryaki1963 on 2012-11-09 22:42:00

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-10 14:17:54

[Former user]

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 :)

Reported by teryaki1963 on 2012-11-10 16:05:32

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-10 19:15:13

[Christopher Kramer]

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.)

Reported by crazy4chrissi on 2012-11-10 19:19:41

[Former user]

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.

Reported by teryaki1963 on 2012-11-10 19:56:26

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-10 21:29:56

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-11 18:00:48

[Former user]

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)
:)))

Reported by teryaki1963 on 2012-11-12 12:15:43

[Christopher Kramer]

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.

Reported by crazy4chrissi on 2012-11-12 12:24:36

[Former user]

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

Reported by teryaki1963 on 2012-11-13 11:38:46

[Christopher Kramer]

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.)

Reported by crazy4chrissi on 2013-01-25 18:48:10

[Christopher Kramer]

Reported by crazy4chrissi on 2013-01-25 18:50:01

[Christopher Kramer]

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

Reported by crazy4chrissi on 2013-03-11 11:21:21 - Labels added: Target-1.9.4

[Christopher Kramer]

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

Reported by crazy4chrissi on 2013-03-14 00:43:59

[Christopher Kramer]

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

Reported by crazy4chrissi on 2013-03-14 23:43:35

[dreadnaut]

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.

Reported by dreadnaut on 2013-03-15 16:00:17

[Christopher Kramer]

> 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).

Reported by crazy4chrissi on 2013-03-18 01:21:49 - Status changed: Fixed

[Former user]

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

Reported by teryaki1963 on 2013-03-22 20:33:45

[Christopher Kramer]

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

Reported by crazy4chrissi on 2013-03-22 22:06:36

[Former user]

Sorry for my bad explanation :)

I uploaded the arabic language file in branch 1.9.5

Reported by teryaki1963 on 2013-03-22 23:00:31

[Christopher Kramer]

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!

Reported by crazy4chrissi on 2013-03-26 17:32:30

[Former user]

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

Reported by teryaki1963 on 2013-03-26 20:24:57