Difference between revisions of "Crowdsourcing Translations"

From GeeklogWiki
Jump to: navigation, search
(added some considerations)
(Design Decisions)
Line 11: Line 11:
 
* Ideally, the plugin should also allow translations of plugins (bundled and 3rd party). We'll start with core texts but try to keep things generic, adding plugin support later when possible.
 
* Ideally, the plugin should also allow translations of plugins (bundled and 3rd party). We'll start with core texts but try to keep things generic, adding plugin support later when possible.
  
 +
Update 24.06.2013
 +
 +
The elements of the LANG arrays can be one word elements or multiple sentences. They can include html code and so forth and so on. They also include common words such as "Save" which can be otherwise included in the page, as a user comment, as a page generated by the static pages plugin... So the big problem is identifying the strings on a rendered page. This is important as the whole goal of the plugin is to provide a context for the translation.
 +
 +
There were several possibilities for solving this. My first idea was to add HTML tags to the array elements such as <span class="translator">.....</span> but the problem with this was that these spans can not be included in places such as the <title></title> or inside a <input value="">. Another approach was to add a API to Geeklog, although this would probably work perfect, and without much hiccups I wanted to avoid doing changes to the Geeklog core.
 +
 +
My (currently) final solution
 +
I went on with the idea of adding some kind of identification to the array elements. Spent some time trying out special HTML symbols such as &#8204. This symbol is invisible for the user, which made it perfect it also was invisible to JavaScript which made it useless.
 +
So I moved on to adding simple text. What I finally have is that all the elements (in the default language file) have these marks: _-start_ and _-end_. I tried to devise something unlikely to appear otherwise on the page.
 +
This change is done when the plugin is installed and is removed if and when the plugin is removed. It will (in the near future) also provide a way to add the identification to other language files (if by some chance the default language of the page is changed).
 +
After doing this, in order to save computation time later I also added data on which array and which element the current string belongs to.
 +
The english.php file now looks like this:
 +
 +
--snippet--
 +
$LANG01 = array(
 +
    1 => '_-start_||array=$LANG01index=1||Contributed by:_-end_',
 +
    2 => '_-start_||array=$LANG01index=2||read more_-end_',
 +
--end snippet--
 +
 +
And here is how the page looks:
 +
 +
[[File:BeforeJavaScript.png|250px]]
 +
 +
Here is how the page looks when the additional text is removed:
 +
 +
[[File:AfterJavaScript.png|250px]]
 +
 +
Read more about this [http://summergeeek.blogspot.com/2013/06/big-decisions.html]
  
 
== Considerations ==
 
== Considerations ==

Revision as of 23:41, 23 June 2013

What is it?

This is a plugin that allows "crowdsourcing" the translation of Geeklog, i.e. once installed, it allows users to contribute translations of Geeklog's user interface texts for other languages.

This is a being developed by Benjamin Talic as a project during the Google Summer of Code 2013.


Design Decisions

  • Any logged-in user should be able to contribute a translation
  • Ideally, the plugin should also allow translations of plugins (bundled and 3rd party). We'll start with core texts but try to keep things generic, adding plugin support later when possible.

Update 24.06.2013

The elements of the LANG arrays can be one word elements or multiple sentences. They can include html code and so forth and so on. They also include common words such as "Save" which can be otherwise included in the page, as a user comment, as a page generated by the static pages plugin... So the big problem is identifying the strings on a rendered page. This is important as the whole goal of the plugin is to provide a context for the translation.

There were several possibilities for solving this. My first idea was to add HTML tags to the array elements such as ..... but the problem with this was that these spans can not be included in places such as the <title></title> or inside a <input value="">. Another approach was to add a API to Geeklog, although this would probably work perfect, and without much hiccups I wanted to avoid doing changes to the Geeklog core.

My (currently) final solution I went on with the idea of adding some kind of identification to the array elements. Spent some time trying out special HTML symbols such as &#8204. This symbol is invisible for the user, which made it perfect it also was invisible to JavaScript which made it useless. So I moved on to adding simple text. What I finally have is that all the elements (in the default language file) have these marks: _-start_ and _-end_. I tried to devise something unlikely to appear otherwise on the page. This change is done when the plugin is installed and is removed if and when the plugin is removed. It will (in the near future) also provide a way to add the identification to other language files (if by some chance the default language of the page is changed). After doing this, in order to save computation time later I also added data on which array and which element the current string belongs to. The english.php file now looks like this:

--snippet-- $LANG01 = array(

   1 => '_-start_||array=$LANG01index=1||Contributed by:_-end_',
   2 => '_-start_||array=$LANG01index=2||read more_-end_',

--end snippet--

And here is how the page looks:

BeforeJavaScript.png

Here is how the page looks when the additional text is removed:

AfterJavaScript.png

Read more about this [1]

Considerations

  • Ideally, translators should be able to see the text strings in context to help with the translation.
    • If that turns out not to be possible, we'll show them without context.
  • It's acceptable if the translation option slows things down. If it slows down things noticably, add a "translation mode", so users can decide between using the site normally or helping with the translation.


To Be Decided

  • Should users be able to freely create new languages? Or do we need some sort of approval process?