Hi Jan, On Tuesday, September 11, 2012 06:52:33 AM Jan Engelhardt wrote:

On Tuesday 2012-09-11 06:17, Max Lin wrote:

...

we prepared an program announcement and we looking for somebody help us translation of the program announcement in the different languages, if you willing do this task, started from http://en.opensuse.org/openSUSE:Conference_Program_announcement would be good!

Where to post the result? A subpage maybe?

http://en.opensuse.org /openSUSE:Conference_Program_announcement /XX

[xx = ISO-639 code]

In my experience, it should be http://{XX}.opensuse.org/openSUSE:Conference_Program_announcement , ex. de.opensuse.org, pt.opensuse.org, fr.opensuse.org, etc. You can found a example in http://en.opensuse.org/Release_announcement , there has different languages link at the left side and almost point to XX.opensuse.org/{Page_Name} Cheers, Max -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Tuesday 2012-09-11 23:20, Tony Su wrote:

Highly recommend posting machine-translated copy using either Google Translate(http://translate.google.com/) or Microsoft Translate(http://www.bing.com/translator)

Both are free and only take seconds then ask for a native speaker review to clean up any idioms and colloquials.

The time to weed out the bugs of automatic translation is close to doing a non-automated, more targeted translation. Especially the farther east you go on the globe (Japanese TL with Google is pretty much unusable in either direction) and/or dealing with highly-technical words (and fillers) - which the announcement is in no way short of, like "Call For Papers", "to keynote", "to kick off", "workshop", "track", "session", "usability expert", and (obviousisms like) "speakers talking". -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Hello Jan (and whoever else receives this, I'm not subscribed to all the mail-lists on CC) Yes, it's quite possible that the initial translations might not be "good enough" -- and ultimately since machine translations today still cannot usually provide better than word for word literal word substitution, "good enough" is probably best defined as understandable although not with the smooth idiomatic linguistic structures that can best be provided by a human being. What machine translation can provide is the ability to get the proper meaning across, to communicate an idea properly. And, if human resources aren't available, this is better than no communication at all. As for accuracy... Particularly for short, "standard expressions" that crop up again and again in the types of documents we produce, Web-based translations provide a means for anyone to submit an improvement or correction. Assuming that Google or Microsoft or whoever is used as the Translation Partner properly evaluates, accepts and implements suggestions for future use of the same expression, we should expect that within rather short order future documents should be translated extremely well. 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. Tony On Sun, Sep 23, 2012 at 1:46 AM, Jan Engelhardt wrote:

On Tuesday 2012-09-11 23:20, Tony Su wrote:

...

Highly recommend posting machine-translated copy using either Google Translate(http://translate.google.com/) or Microsoft Translate(http://www.bing.com/translator)

Both are free and only take seconds then ask for a native speaker review to clean up any idioms and colloquials.

The time to weed out the bugs of automatic translation is close to doing a non-automated, more targeted translation. Especially the farther east you go on the globe (Japanese TL with Google is pretty much unusable in either direction) and/or dealing with highly-technical words (and fillers) - which the announcement is in no way short of, like "Call For Papers", "to keynote", "to kick off", "workshop", "track", "session", "usability expert", and (obviousisms like) "speakers talking".

-- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu, 27 Sep 2012 11:38:44 +0200 Jos Poortvliet wrote:

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