On Thu, 27 Sep 2012 11:38:44 +0200
Jos Poortvliet <jos(a)opensuse.org> wrote:
On Wednesday 26 September 2012 15:18:09 Tony Su
If there is any interest in openSUSE/SUSE to investiggate the
capabilities of this technology, a project should be designated that
can properly evaluate whether machine translation is worthless or
promising and if desired I am willing to shepherd it.
'shepherd' or 'do' ;-)
Unlike metaphorical shepherds, in a real shepherds world there is no
such philosophical distinction, it is all do.
I wouldn't know what would be needed to actually
TEST this out - but
you're right that there are plenty of pages not translated in plenty
Quite a few of our sites are in github, maybe you can set up a test
Site translation is not trivial compared to article translation,
Then there is the wiki. How do we support our
translators with this,
can google translate be helpful for that?
Problem is that our wiki "structure" is complicated to translate. It
was created to alleviate some problems in old wiki, that made it
unmaintainable mess, but whole process was unnecessary rushed and we
ended with another set of problems.
From distance of few years it is obvious that many things can be done
differently without complicated page structure that makes automatic
translation nearly impossible.
For example, maybe it is possible to have an
over our wiki pages ... Then people can edit as things used to are...
Is that possible?
Yes, but not on all pages.
Most likely it will need a lot of manual work to separate
translatable strings from page layout.
Is there a mediawiki tool which can crawl our
wiki and, for pages that have no de.opensuse.org
etc etc equivalents, create and fill them? If you
'just' manage to do that, our wiki has become far more accessible to
There is for sure.
Besides extensions, there are tools all over Wikipedia used by editors
and for sure there are some crawlers that update translations. Years
ago with old wiki people just copied Wikipedia ideas including their one
server per translation model.
There is also extension used on http://translatewiki.net
and some other
sites that can help, but someone has to learn how to use it. It can
help us translate about anything, including software strings.
When I say someone I do not just give idea with no wish to work, but
also admit that if project depends on me and my time it will be done in
a much longer period then with someone else that already has
experience, or simply learns faster.
Exactly that lack of time was a reason that wiki transition was filled
with errors. I tend to spend time to understand subject, learn about
it, and then act; as transition was rushed, I was always behind the
loop. When I was done with research and wrote report, it was too late
as a lot of effort went into certain direction that you can see in
current wiki. Many, if not most, of those reports were discarded.
Above is another fact of life that makes cooperation on tasks hard for
me and probably anyone like me. We do the work, but development goes in
different way, sometimes clearly in a direction that more experienced
on the subject consider wrong (Wikipedia editors). After few attempts we
just give up. Without own server that costs money and takes away
precious time on administration tasks, we can't test, or design, any
solution that will contain results of required research and analytics.
In this particular case:
* research existing translation solutions,
* list them with synopsis of good and bad (to get to synopsis, we may
spend 6 months, or more, learning tool that we write about)
* weigh pros and cons - in discussion play scenarios like in a chess,
what if I use this, then users will do this; what user type A, B, C
can do with this. How many users we gain or lose.
* make a sketch of a solution
* split task to blocks of sketched diagram, or list, and work on details
* when done start implementation.
* be happy when all is done in 2-3 years.
Crowd-sourcing does not mean that one has to abandon planing phase,
which many implicitly do, like one can design so many solutions
that will compete and the best will win. This can work with hammer
design, but with toolbox it will already have so many components, that
some not so good solutions will survive for a long time. Worse, impeding
development of proper ones, just because users got used to them, make
workarounds for tool deficiency, and now will have to spend time to
learn new tools.
Example of systemd.
It is better, even it has rough edges and missing features, but people
will have to invest months to learn how to use it, before they can spend
years transferring old working configurations to new system, and at the
same time they will have to maintain existing solution running. With
tempo it is pushed now, there is no chance it will make a lot of
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org