[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [babel-dev] Non-translatable strings, general rules of translation (was [babel-translators] New Translator joining)
|
Hi Sean, see my comments below:
On Tue, Dec 23, 2008 at 7:44 AM, Sean Flanigan
<sflaniga@xxxxxxxxxx> wrote:
Denis Roy wrote:
> For translations, I don't think I would translate terms like this one:
> 00:03 pluginProvidedJsfLibraries -> BibliothèquesJsfFourniesPlugin [fr:
> extension-point.name.1
> <http://babel.eclipse.org/babel/translate.php?project=webtools&version=3.0&file=org.eclipse.jsf/components/jsf/plugins/org.eclipse.jst.jsf.core/plugin.properties&string=extension-point.name.1>]
> *webtools 3.0* (Corina Roe
> <http://babel.eclipse.org/babel/recent.php?userid=57421>)
>
> Not all the externalized strings in Eclipse are actually meant to be
> translated. If you're not sure, you can try looking at the translations
> from another language, or you can ask this list. [babel-translators]
If another translator had already decided this string was
non-translatable, and marked it as such, Babel won't even allow a
translation to be entered, so there would be no need to look at other
translations. Corina was really in uncharted territory in the case of
this string!
Would you advise any or all of the following as general rules?
1. Don't translate the string "Eclipse.org".
2. Don't translate any string written in camel case.
3. Don't translate any string with a *key* that starts with
"extension-point.name." . [1]
4. Mark any such strings as Non-Translatable instead.
I would not advise such rules, this is really up to the developer who externalized the string.
Come to think of it, there ought to be a wiki page for general rules of
translation, a bit like http://wiki.eclipse.org/French_Glossary but not
locale-specific. Is there one already, or should I start one? I'm not
a translator, but I can provide a Java programmer's perspective. I
don't know Eclipse/OSGi conventions all that well, but I could at least
make educated guesses, and provide a starting point.
In most cases, the original programmer should know if the string is
meant to be translated better than anyone. It would be good if we could
convince the plugin's programmer to review the resource bundle in Babel,
marking any items they recognise as Non-Translatable configuration. (It
would help if the programmer could mark the bundle in Babel to say
they've reviewed it for translatability.)
That's what should happen.
I would be happy to review other programmers' resource bundles myself,
but how good are Babel's abilities to review Non-Translatable decisions,
in case I get some of them wrong? Do they show up in Recent
Translations, by any chance?
No, we need more tools to diagnose and refine translations, or non-translations.
[1] One of the other extension point names is "jsfLibraries", but others
look more like normal English: eg "Property Resolver Ext Point" and
"Method Resolver Ext Point". I get the impression that we don't want to
translate extension point names, whether they are in camel case or not.
Is this correct?
Nobody on this list can answer this question, the developer would need to answer that. Depending of the extension point, its name might or might not be translatable.
I'd be for having a contact system to ask the original developer of what should be translated or not, and ideally request context on translations.
Here is the process I follow when it comes to translating:
You have limited time, and a large number of translations to do. Do several passes: during the first pass, skip anything that you don't understand or doesn't make sense. Then come back to it, note what's really hard to translate, and contact the developer.
Thanks,
Antoine
