Design for Colloborative Translation Tool
By Purus
Hi all,
This thread is the continuation of http://community.elgg.org/pg/forum/topic/808710/collaborative-internalization-for-elgg/.
Here is my initial design for the colloborative web based Translation tool.
Approach:
- The user will upload the plugin in .ZIP format to this webbased tool. The same will be done for CORE too.
- The tool will automatically unzip the file and reads the manifest.xml file to get the Plugin details. The details will be added to the PLUGIN_MASTER table.
- Then the php files inside the languages folder will be scanned and will be read individually.
- Each and every language key and value of each language file will be parsed and loaded in to the PLUGIN_STRINGS table.
- Then all the loaded strings will be shown in a new page for the users to translate each string in the language that they need.
- English will be considered as the standard language and will show up the string for other languages with the % of translation completed.
- User can add a new language for the plugin, if it is not already translated in that language.
- For each custom language selected, all the string will be displayed. User can report a particular string if the translation is not correct. For this string, the column str_marked will be TRUE.
- Other users can validate the strings for which the str_marked column is TRUE to come up with the better translation.
PLUGIN_MASTER Table:
plugin_id : Integer,Autogenerated, Primary Key
plugin_name : Text(30)
plugin_version : Text(10)
plugin_author : Text(30)
plugin_tms : CURRENT TIMESTAMP
PLUGIN_STRINGS Table:
plugin_id : Integer,Autogenerated, Primary Key
str_lang : Text(5)
str_key : Text(50)
str_value : Text(200)
str_marked : Boolean - Default value of FALSE
plugin_tms : Insert TIMESTAMP
plugin_updt_tms: Last Update TIMESTAMP
PLUGIN_LANGUAGES Table:
iso_lang : Text - Holds the valid ISO language names
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
Your suggestions and feedbacks please !!!
#1
Stop posting back on the older thread ;-) lolz
Those interested most likely already got to the new posts ;-P
#2
Isn't ISO Lang Key 2 - 3 chars ?
#3
plugin_name (30)
str_key (50)
str_value (200)
-- might be a little on the short side.
MASTER(Vers) <-->> STRINGS(No Vers)
-- might have issues if need/want to track
individual strings qualified by Version# within Strings.
#4
See what comes of :-
PlugIn (v 1..99)
--> Language Code (ISO)
--> Language String (v 1..999) [not == PlugIn Vers]
you might want to do this all in something like github and make your comments here pointing your topic to code on github.
check this out http://progit.org/book/
@DDS:
1) LOL
2) Maximum it can be of 4 chars. Just given more spaces for design.
3) The above lengths are just for reference.
4) I belive you will be always right. But I am not able to understand this point. :) More info plz.
@Steve: I am not going to move the code to Github, atleest untill the coding is fully done. Github is not much helpful for this tool.
Please read the old thread for more information about this.
U R right - ISO 639-6:2009 Pt 6 covers alpha-4 codes ;)
Guess this does not looks okay for the guys out here. I am waiting for the feedbacks and comments.
I am REALLY pissed off as I have just continued the Hungarian localization on Launchpad to find out two hundred strings later that the translation on Launchpad has been DISCONTINUED...
Isn't it just killing the only skinny cow at the farm for the sake of having nothing as replacement?
Just take a look at this subpage for the .hu language file. It has all the answers and probably more, all ready-made, for the questions that this discussion and its predecessor involves.
Wouldn't it be just having Launchpad back as a translation tool for the language files while leaving all the rest of the version management on Git?
I am fine with anything, as far as the tool can provide good framework for translation.
Well, this one needs core project management decision - unlike spontaneous forking, this is something that would disperse development (first code at github, on the other hand, translation on another development support site, in our case, launchpad).
Did you take a look at Launchpad?
I guess that when it was abandoned, it's been in a much less developed state that now. One must think about a return...
- Previous
- 1
- 2
- 3
- Next
You must log in to post replies.