On Thu, 27 Sep 2012 11:38:44 +0200
Jos Poortvliet
On Wednesday 26 September 2012 15:18:09 Tony Su wrote:
... 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 of languages.
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?
It can. 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 auto-translate run 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 en.opensuse.org wiki and, for pages that have no de.opensuse.org, fr.opensuse.org etc etc equivalents, create and fill them? If you 'just' manage to do that, our wiki has become far more accessible to non-native speakers...
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 friends. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org