2011/8/2 sankarshan <[email protected]>
> On Mon, Aug 1, 2011 at 11:31 PM, Karunakar <[email protected]> wrote:
>
> > Now its not that we have to develop a new one from scratch, but find a
> way
> > to manage the volume of translations and keep consistency across
> > applications, now efforts like FUEL have targetted that, but still we
> have
> > not got to completely applying it across all Hindi translations.
>
> Alright. Let me re-iterate over what I see as aspects that need to be
> thought over.
>
> - infrastructure : does IndLinux actually have the time to invest in
> resources around it. Putting up an infrastructure means ownership and,
> the obvious downside to that is liability
>
>
Frankly time is not the worry.. its more of lack of initiative that's
worrying!
Though I have not been able to focus on it much in last couple of years for
personal reasons, but I feel its a doable thing and wont require much time
maintaining once up and running.. cost/hosting is one part, other being
putting it up - which is basically reviewing all the available tools, and
then putting together something that suits the need, which to state are
- keep consistency
- keep projects upto date (to the extent possible) for Hindi.
- use the memory with new projects (so new project with few hundred
strings to be translated could be reached at 50-70% completion instantly).
So more on ownership and liability etc,, I feel its better to start
discussing on the solution.
> tooling : putting up a tool viz. Pootle to be an help allow aggregation for
> language/locale/script makes IndLinux the downstream
> of upstream projects for that specific language/locale/script.
>
>
Since across the major projects, ppl active on Hindi l10n are handful, we
will come to a common understanding to use a common translation base and
push that upstream.
So idea is not to track work, or who is doing what, but manage all
translations within one framework. Its not necessary for project to use
content from it, but initial stage will be the aggregation where we will try
to extract common stuff from all projects. At a mature stage this can be
used to push translations upstream. This framework is not to be used from
day one, but only once the maturity is reached that all translations
aggregated are consistent and correct (at the least spelling wise).
> - translation consistency : a very important aspect. I made that point
> clear in my response to Christian as well. Most upstream projects
> don't give enough importance in their timelines to ensure that.
> However, a tool like Pootle isn't pretty much suited to a review aimed
> at achieving some sort of consistency. Unless you merely aim to load
> Pootle with the FUEL word-list and aim to use the translation memory
> to do multiple runs over the specific language and all projects
> underneath it.
>
>
Pootle would be mainly used as interface to to minor translation works, wont
be using same backend. Idea is like start with standardized list like FUEL,
gnone-glossary, then build on it organically, while adding existing
translations into the framework and vetting them, and use it as memory for
doing new work and keeping existing l10n work up2date.
Along the lines of the last point, for a while now, Kushal (Das) has
> been maintaining a tool called translation filter (I may add, created
> at the very urgent prodding by Runa) which has enabled Bengali to
> maintain a high degree of consistency and, same-ness across the
> projects and translation-ready objects. You may want to look at that
> or, similar tools rather than hosting a translation interface.
>
>
Idea is not to have someone running tools manually as per need basis, if
tool can be used in automation then yes it will be useful.
Standardization follows consistency. You'd need to check for
> consistency first and then standardize.
>
>
Enough of that effort has happened for Hindi..(ie terminology, and short
phrases in translation). But volume has become unmanageable.
Karunakar
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
IndLinux-group mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/indlinux-group
