[geeklog-devel] CrowdTranslation plugin

[Niemans]

Let's dril down a bit more on the real environment.

The translation, seen in a generic way, has two use cases.
A first use case exists for a local geeklog site and will support doing actual translations locally. Which could make use of moderation.
A second use case exists for the main site and will support the merging of translations that local sites "release". Which must use moderation for the released translation. No editing.

So, in short, local sites conform to the first use case. GL mainsite conforms to the second and could also conform to the first use case. We must be careful to not complicate the use.
Key principle is that any translator site has credentials or a minimal translatorID, also the GL main site.

Let's have some figures.

Say, I'll do the dutch translation locally. After finishing the bundle will be released to the main site and world-moderation starts. After a while this moderation ends and the language files are incorporated in the next official GL release.

Say, mr. Henk Jansen wants to do the same. The mainsite ends up with two releases for Dutch ! These releases would not have to be identical, nor 100% complete. The world-moderation will filter.

Say, being a huge success, some local site will act as the mainsite and merge a few releases into their local repository and releases the resulting bundle to the GL mainsite.

So, in extrema, GL mainsite has 25 original languages and total 81 releases will be merged / moderated. This has to culminate into one official release of GL.
So, we may expect that these 81 releases do not cover EACH language in full 100%. I can think of me doing LANG01 and Henk doing LANG02 or we both translate just randomly during a fixed period of time. We did not yet talk on "coverage" on completeness.
To my opinion, this triggers the design decision: do we release/export a complete language (with holes in it) or do we release/communicate single items, as time goes by?
In other words: is the mainsite like a vacuum cleaner and will hold a near-copy of the co-operating local site OR is the intention to support a start-stop process with complete or merged releases from local sites? Important factors here are the expected use of the plugin, the volume of kudos we assign to the co-operators, the need to be fast in publishing, conformation to a schedule.

Can we vote?


Wim

Op 16 jun. 2013, om 21:09 heeft Niemans het volgende geschreven:

> 
> Let's drill down a bit on the starting points.
> 
> My first guess would be that the language items would be present in the database.
> This results in the requirement to load these language items. It is obvious that we need a step too to export them, which could be implemented item-wise or language wise.
> So, if the database contains the language items, we also do have a language list by querying the database.
> If we agree on my guess, when the user enters "engslish", than that means a new language by the simple fact of the absence in the database.
> My guess would than be, to create a new language in the database with all items already populated; this is needed to avoid that new items will be created which have no use in the base code.
> 
> My second guess would be that a approval process would be better a moderation process. So, anybody can register (at the main site) for a translation, receives some credentials to load in his/hers local database which could be checked by the plugin, probably at install time. That's approval.
> After export of a translation, we need people to moderate, which could be crowd sourced also. My preference would be that moderation occurs at the main site with released (exported) translations.
> 
> My third guess would be, that the progress of a (local) translation could be monitored by a rss-feed.
> 
> Shoot!!
> 
> Wim
> 
> 
> 
> Op 16 jun. 2013, om 20:39 heeft Dirk Haun het volgende geschreven:
> 
>> Benjamin Talic wrote:
>> 
>>> Now I face the first big design question, do we let the user add any new language they want to e.g. provide them with a text input box.
>>> Or are they allowed to select one of a list of previously provided options-like they do when they pick the language for the site?
>> 
>> Since the whole point of this project is to harness the power of the crowds, I think we should allow users to submit translations for new languages. However …
>> 
>> 
>>> The downside of the first option is that users could input stuff like Engslihs instead of English which would create a new 'language translation'.
>> 
>> 
>> This could in fact be a problem.
>> 
>> My first thought was to have some sort of approval process: Allow users to suggest a new language for translation, but only after it has been approved (and possibly corrected) by an admin user. But if we make this too complicated or if it takes too long, it could demotivate the potential contributor.
>> 
>> Thoughts, anyone? Other ideas?
>> 
>> bye, Dirk
>> 
>> P.S. We're going to use http://wiki.geeklog.net/index.php/Crowdsourcing_Translations as the project's "home page". Anyone interested may want to keep an eye on that page.
>> 
>> 
>> -- 
>> http://www.themobilepresenter.com/
>> 
>> _______________________________________________
>> geeklog-devel mailing list
>> geeklog-devel at lists.geeklog.net
>> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>