Rosetta

[Dwayne Bailey]

I'm trying to troll through mail and am avoiding the Rosetta ones till I
get some sanity.  I've briefly looked at a few and liked the feedback
I'm seeing.  Especially the concern about glossaries and consistency.

Some things I thought about while at OOoConf and would like to discuss
is ... (and had hoped to talk to Dafydd about - as we sipped coffee in
completely different parts of Heathrow airport):

- The portal lowers the barrier to entry which I think is good but how
low should be make the barrier?  You have to be able to code to
contribute to the Linux kernel.  Otherwise you're shouted our of the
arena.  Maybe we shouldn't be so harsh but still how do we ensure that
people who contribute can actually translate?  A source project will not
be able to evaluate the quality of supplied translation.  I know the
Welsh team had a two stage process - but would like to hear other ideas.

- How do we ensure that this tool assists existing translators/teams to
be better instead of being a complete pain for them.  In speaking to the
Khmer and Swahili teams (generally about portals not specifically
Rosetta) bandwidth is an issue.  ie it would help them if they could run
it locally.  I have similar concerns when I run translation events next
year I don't want to find that the University we're engaging with has
terrible bandwidth and thus our efforts are dismal.

On Thu, 2004-09-30 at 11:46, Dafydd Harries wrote:
> Dwayne Bailey had a look at Rosetta recently, and I thought I'd forward
> his comments to the list, along with some replies from me. This feedback
> is really useful -- thanks Dwayne!
> 
> Ar 16/09/2004 am 00:56, ysgrifennodd Dwayne Bailey:
> > I like
> > ------
> > - The dashboard - although formating got wonky on some pages
> 
> I think the dashboard has been improved since you looked at it.
> 
> > - Personal list of projects
> > - Suggest a project
> > - Download PO files to translate offline or translate online
> > 
> > 
> > Don't like
> > ----------
> > - Multiple languages shown in the translation interface.  More likely to
> > create bad translations then assist
> 
> I'm sure we could improve the interface for the common case of
> translating into one language at a time.
> 
> We're planning to develop a feature where one can display multiple
> languages in a read-only mode. For example, a translator for Brazilian
> Portuguese might well find existing translations for Portuguese from
> Portugal useful while translating.
> 
> > - Getting to the translation interface was quite complicated,  Would be
> > nice to be there almost straight away.
> 
> Agreed, the navigation is a bit clumsy.
> 
> I'm hoping this is mitigated by the fact that once you've found the
> right template for the first time, it can be added to your list and will
> show up on your dashboard.
> 
> > Would like
> > ----------
> > - More stats on dashboard like rate of change expected date of
> > completion, etc
> 
> These would indeed be useful. A simple indicator of how complete a file
> is on the translation page would also be useful.
> 
> > - An idea of what the target for a package is
> 
> In terms of percentage complete?
> 
> > - More aids on the translation interface (highlighting cues - eg
> > variables, HTML, etc are different colours; pre-commit checks - eg
> > accelerator checks, variables correct to stop errors early)
> 
> Absolutely. Hilighting interpolation sequences should be fairly easy.
> These messages will have the c-format flag set. Detecting XML/HTML would
> be a little trickier, but it's certainly doable.
> 
> Checking translations before they are written to the database is
> definitely something we need to do.
> 
> > Couldn't really check
> > ---------------------
> > - Translation interface - got errors on commit
> 
> Are you still getting these errors? Hopefully they'll be fixed by now.
> 
> > - How you determine readiness
> 
> What do you mean by "readiness"?
> 
> > - How you handle project such as Gnome and KDE which have hierarchical
> > groupings of translation files vs Evolution or smaller projects which
> > usually only have one file.
> 
> There's still work to be done on handling large projects well, but we
> have some ideas on how to do it.
> 
> > - How you store stuff in the backend
> 
> All our data is stored in a Postgres database.
> 
> > - How you would interact with the upstream projects localisation effort.
> 
> The need to work well with translators working outside of Rosetta is
> something we're very aware of.
> 
> > - One translation section indicated missing plural info so not sure how
> > you would handle plurals
> 
> Plural forms are something which it's very difficult to present in an
> obvious fashion. I think users will need to learn what plural forms are
> in general and what the plural forms are for their particular languages.
> Of course, if Rosetta can help the user to understand it, then by all
> means it should.
> 
> > - KDE and gettext style comments not sure how these would come through
> > in the interface.
> 
> This is something we're planning to add soon.
-- 
Kind regards
Dwayne Bailey

dwayne at translate.org.za   
+27-12-343 0389 (home/work)  +27-83-443 7114 (cell)

"It would be a profound irony if an earnest attempt to bridge
the digital divide unravelled because of prohibitive software
license costs.  Even with educational discounts and so forth,
the proprietary model does not offer the unfettered choice to
participate in the development or modification of the very
technology that can only increasingly become an intimate part
of any developing society as it ventures into a digital
future." - Dr Sibusiso Sibisi, President CSIR, South Africa

Translate.org.za - Opensource software for all South Africans
A project of the Zuza Software Foundation