PHP System for translators

[MaV]

Though I've sent an email thru forums to admins, I got no reply so maybe they didn't receive it? Anyway, I'll repeat this here.

I noticed an announcement on download page that You need a PHP administration system for translators. I have experience in writing applications in this language, so I think I can help with it. I need to know how it should look though and how shoult it work. Can some admin reply here on this? Comments from other translators on this are too apprieciated. I'm only a coder, so some other person will have to make some (but not too advanced I think) layout for this.

[JAM]

I've done the same thing, but without any reply...

Perhaps more ideas coul dmake it abit better.

Edited: Removed link

[archivator]

I spoke to ludde over IRC, and from what I undestood he needs a data verification system for the language files.

It is fairly easily done, but there needs to be an option for adding new strings. I was quite interested in the whole structure of the files and it seems that there is no order, but there are several english strings with the same text in which cases the order does matter. It's all that complicated, but I'm now working on a proper parser. I was thinking of adding all the English strings into a database and then simply analyze the fileusing them (checking whether they all exist and whther there is a translation). Sounds quite easy, doesn't it?

[MaV]

I thought about some diffrent approach to this.

There would be a database of translations for each language. To make changes, user will have to register in the system, and this admins will verify (to cut off spamming and vandalism). After login the system will load current translations (for each version - about this a bit later). User will be prompted to fill all missing translations (if this was a new version) or make necessary changes. Once per day an email or PM to admins will be dispatched to inform he that something changed (if so) so he can update language pack. OR the system will generate language (txt) files on-the-fly and put them on the website to download.

On the admin side - after logging in admin would have possibility to edit base template file (add / modify / delete entries, preserving their order, adding into specific position), add new language and manage users (adding / deleting them to/from language maintenance). As for new versions - I see it this way - every change (or set of changes) in base template file will make a new version to translate. Every translator (that wants it of course) will be notified about this and will have highlighted lines that were added/changed.

That's how I see this. Of course You can approve or ignore this. I just thought that this kind of system would simplify translation works pretty much .

[archivator]

Yes, that's probably the most suitable way of doing it but it is also the hardest to develop. What happens to backward compatibility? Not to mention the fact that there will be like 30 tables each consisting of 500 rows. Pure waste of space, IMO. I say we choose a way of doing it, discuss the specifics, and start doing it

[MaV]

Developer(s) of uTorrent are working hard, so can we . I think space isn't a problem - this would take a lot less of space than, for eg. this forum. And backward compatibility - every version of language file could be saved for each language. It's fastest to implement, although will take [no of strings] * [no of languages] * [no of versions] rows. But we can live with it - again, I think still these forums will have more posts than that .

[JAM]

I'd like to mention the phpbb type of way:

$lang['Restore_Error_uploading'] = "Fel när filen skulle laddas upp.";
$lang['Restore_Error_filename'] = "Problem med filnamnet, försök med en annan fil";

This is ofcourse just two small examples showing the php way of adding variables, but you should be able to get he point. Something similiar to this would make the earlier idea of using databases abit easier to manage.

This needs 2 tables (one for original, one for all other translations), and just perhaps one more if some more advanced "admin-stuff" is needed.

And waste of space? Well, space is hardly an issue in this case, imho. First of all, the language file is rather small. Then the word waste combined with something that deals with the continued development of uTorrent just doesn't match.

[MaV]

It could be fun writing all this . But still, we need confirmation from ludde to make sure what is needes, so we don't code for nothing.

Oh, some screen of pre-pre-alpha version of me working on my idea: http://mav.subfan.pl/uts.png

[easyx]

Nice idea Mav, the best thing that all translators will need, I think, is to be able to see in every new version the changed/new strings.

This way the translator can translate quick the new strings without searching for their position in the lang file.

Also it's good the lang file to be created automaticly by the system for each language, this way all the lang files will have the same structure and the strings will be in the same order.

Maybe it' ll be good if possible to add a .log importer to the system so when a new vesion of μTorrent comes out, the system will import the log and it 'll create the new base lang file ( it 'll be something like a patch ). The option to import .log files may be available only to the developers of μTorrent ( ludde, vurlix ) to help them add instantly the new strings, just run μtorrent with the previous lang.txt file, and import the produced .log in the system, then the system finds the differences and adds or modifys strings.

[pckilla]

I think translations database should look like

id - auto increment

language - en_US (or template for template string), et_EE etc.

translate_id - template strings id

string - some text

from_build - 380

to_build - 392 or NULL if string still exists in current version

translator_id - who translated this (id from separate users table)

if needed, there could be columns for added date, edited date and editors id and then its easy to generate specific langfiles for each version and its all in one database table.

[hin123]

Maybe the translation system can generate a language file for the translator to see how it looks like in µTorrent?

[dAbReAkA]

it should generate the language file for u to test and edit if there is something wrong with it. after u asure that everything is OK u can submit it by form to the person responsible for the language pack

[easyx]

Another one idea for the system is to have a main languages table in the database with the following columns:

id - probably auto_increment

template base language - in this column each row will be one string

columns for other languages - in each row will be the translated string

id |English_Template|Language1|Language2|

1 | String1 | String1 | String1 |

2 | String2 | String2 | String1 |

. . . .

. . . .

. . . .

And then another one table which will store the version info.

More specific will have a column e.x. version_number which will store the version number e.x. 1.4.0 and another one column which will store the ids of the strings wich existed in that version e.x. 1;2;5;7;8 or with some other format.

version | Strings_id |

1.3.0 | 1;2;3;5;8.... |

1.3.1 | 1;2;3;5;8;9;.|

. .

. .

. .

We 'll need some more tables of course for user rights and other required information.

These are just some thoughts, I hope to be useful.

[pckilla]

Dont see the point of making separate column for each language and separate table for versions...

[archivator]

easyx, if we do it like that, we won't be able to use the native MySQL functions to grab the records (it will be possible, but at the expense of longer query time).

I say we stick with something, make the declarations of the functions (not the functions themselves, like C-style declarations), add the proper comments (@author, @param, @return, etc.), X-Ref the whole thing and put it somewhere on the net. Then, we can all see what the functions will do and start working on them.

Btw, is it gonna be OO or simple functions-based?

[MaV]

I think that's strings id won't do, because many times strings are modified, not added in new versions. What then ? Besides, it's generally a bad idea to dynamicallt add columns to table.

I see it this way:

Table: uts_languages

id | name  | description
-------------------------
1  | en_US | English (US)
2  | pl    | Polish
3  | it    | Italian
...

Table: uts_strings

id | string       | lang | build 
-------------------------------------
1  | some string  | 1    | 400
2  | other...     | 1    | 400
3  | ...          | 2    | 403
...

And of course table with users.

I'm working on it right now. I'm documenting everything so anyone can edit this later. I personally don't see point in OO programming on smaller projects, so I think funtions will do the job just fine.

Edit: Someone knowing CSS and willing to help here ?

[MaV]

Hm... Okay, something like this then:

Table: uts_strings

id | string       | build_from | build_to | order | comment
--------------------------------------------------------------
1  | some string  | 400        | 403      | 1     | used in...
2  | other...     | 400        | 402      | 3     | some comm
3  | ...          | 403        | 403      | 2     | ...
...

Table: uts_translations

id | string_id | text         | lang 
------------------------------------
1  | 1         | some string  | 1
2  | 2         | other...     | 1
3  | 2         | ...          | 2
...

With this a simple query could display whole translated strings from any language and build, while still not eating too much memory. What do you think?

[archivator]

Guys, I wanna help with this, but how do we do it? From what I'm seeing, everyone's working on his own version. I don't know for you, but I call this a waste of work. :-/ Let's stick behind one idea and just start working on different parts of it.. Btw, ludde said there are several strings with the same content, but used in different situations. They may be translated in a different way depending on the context. What do we do then?

[MaV]

I have some work done (account registration, validation) etc., so we can continue this, unless someone have some more advanced script already done.

Btw, ludde said there are several strings with the same content, but used in different situations. They may be translated in a different way depending on the context. What do we do then?

Maybe add 'comment' column to base strings table so ludde can add a description for translators where string exists or etc. ?

[pckilla]

There is no need for two separate tables, it can all be done with that first one (uts_strings). Or make one table for template (id, string, from_build, to_build, string_order) and other for translations (id, template_id, lang_id, string).

I think there should be string_order column, so when generating langfile correct string will be placed at correct line for utorrent program. Otherwise all new strings must be at end of file, but they aren't.

[MaV]

With two tables we're saving us from duplicating strings and build info in every language entry, and it's better, don't you think? . And it's be a lot easier to manage orders only on strings table I think.

Edit: Oh yeah, I was thinking about the order column, but I forgot to add it here. Updated.

[pckilla]

If uts_strings only conatains template strings, then it doesn't need lang column.

And separate comments table (id, string_id, comment) would be very useful, cause sometimes it is very hard to translate something if I dont where and for what that string is used.

[MaV]

Oh, you're right, my bad . Updated.

Edit: I think comments can be in strings table. Like this (see above table).

[pckilla]

Thats good too

Translations table should include translator_id column

[MaV]

Hm... I thought about translator_id, but what it should contain? If, for example I translated some string, and then someone else modified it - should it contain my id or this person's id?

Oh, and one more structure, uts_users table:

id | username | password | email | language | status
----------------------------------------------------
1  | MaV      | [md5]    | ...   | pl       | 1
2  | emc      | [md5]    | ...   | cz       | 1
3  | some guy | [md5]    | ...   | xx       | 0

Passwords are hashed with md5. Status is active/inactive flag, and maybe can be used to determine user level, but that's other history.