On 27.11.2018 13:13, PÉNET Ludovic wrote:
Le 27/11/2018 12:01, André Warnier a écrit :
On 26.11.2018 17:01, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Rémy,
On 11/26/18 10:05, Rémy Maucherat wrote:
[...]
A corollary of this is that the error messages and the documentation
should agree with each other. Do we have French-language documentation
for this stuff?
+1
I believe that this is the important point, which I tried to
illustrate with the tongue-in-cheek example above.
+1
I must say that, although I tried to participate as much I could, I
have some reservations about this whole translation project. And that
is because most of the original messages which I have seen, are really
"technical" and not at all oriented to a general public which may be
using applications built on tomcat, but rather to a public having to
deal specifically with tomcat Java code and tomcat configuration
files.
This public is going to need messages which they can later connect to
that code and/or to the configuration files language and/or to the
available documentation.
And let's face it : in terms of anything computer-related,
non-native-English-speakers (such as myself) lost out a long time ago,
and have had, and will have, to learn a modicum of English technical
computer language anyway, just to understand the basics of their field
of expertise.
That is not what most of us would culturally prefer, but it is a fact of life.
+1
[...]
I would go to https://translate.google.com, paste in the above
message, and instantly get :
French : "Impossible de trouver la classe principale:
org.apache.catalina.startup.Bootstrap. Le programme va sortir."
German : "Die Hauptklasse konnte nicht gefunden werden:
org.apache.catalina.startup.Bootstrap. Das Programm wird geschlossen."
Spanish : "No se pudo encontrar la clase principal:
org.apache.catalina.startup.Bootstrap. Programa saldrá."
Polish : "Nie można znaleźć głównej klasy:
org.apache.catalina.startup.Bootstrap. Program zostanie zamknięty."
(Note : I don't know anything about the Polish language, just adding
it for the fun; but also to ilustrate that the same website provides
dozens of target languages.)
The point is : are any of the above worse/better than what we get by
this current quite time-consuming one-off (but to remain relevant,
regularly repeated and maintained) translation effort, in the
perpective of the potential users of these messages ?
IMHO, you took an easy example... In a lot of cases, Google Translate was of no
help when
trying to translate some more difficult strings. As pointed before, the
original English
sentences are sometimes, hem, not Oxford English or the vocabulary really too
specific.
1) disclaimer : I do not have any employment, commercial or other relations
with Google.
2) I did not really take an "easy example". Well yes, I did : it just happened to be easy
in the sense that it is was the first error message in a tomcat logfile that was lying
around on my laptop.
But what I did do, was to take a complete sentence out of the logfile, and not just one
word at a time, or a sentence containing "markers" (like the "{n}" things of these
prototype messages we just translated).
Google translate seems to work many times better when what you feed it, are complete
sentences instead of just words.
(Note: I did not really find this out, out of the blue. I found out because I was recently
doing some marketing-text translation of my own, from German to English to Spanish, and
although I know those languages reasonably, it was still a good help in merely
figuring-out the style of the translations for phrases, and some specialised vocabulary).
3) I have tried more tomcat log messages since, and the results seem to be relatively
consistent, as far as I am concerned.
Following are some additional examples taken from real tomcat logfiles, including some of
which I remember seeing while translating in POEditor : (I'll just put the French
translations this time, to stay in tune with the current thread; but I have checked the
translation in some additional languages, and they look of similar quality.)
"SEVERE [ajp-nio-8009-exec-7] org.apache.coyote.ajp.AjpMessage.processHeader Invalid
message received with signature 18245"
--> "SEVERE [ajp-nio-8009-exec-7] org.apache.coyote.ajp.AjpMessage.processHeader Message
non valide reçu avec la signature 18245"
"Note: further occurrences of HTTP header parsing errors will be logged at DEBUG
level."
--> "Remarque: les autres erreurs d'analyse d'en-tête HTTP seront enregistrées au niveau
DEBUG."
"java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method
names must be tokens"
--> "java.lang.IllegalArgumentException: caractère non valide trouvé dans le nom de la
méthode. Les noms de méthodes HTTP doivent être des jetons."
(I admit that "jeton" may not be the best possible translation for "token" in the tomcat
context, but it is linguistically correct)
" org.apache.tomcat.util.http.parser.Cookie.logInvalidHeader A cookie header was received
[...] that contained an invalid cookie. That cookie will be ignored."
--> "org.apache.tomcat.util.http.parser.Cookie.logInvalidHeader Un en-tête de cookie
contenant un cookie non valide a été reçu. Ce cookie sera ignoré."
"org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request
header"
--> "org.apache.coyote.http11.Http11Processor.service Erreur lors de l'analyse de
l'en-tête de la requête HTTP"
"org.apache.coyote.ajp.AjpMessage.processHeader Invalid message received with
signature 768"
--> "org.apache.coyote.ajp.AjpMessage.processHeader Message non valide reçu avec la
signature 768"
"INFO: Index is not optimized therefore skipping building spell check index for:
a_spellPhrase"
--> "INFO: l'index n'est pas optimisé. Par conséquent, ne pas créer d'index de
vérification orthographique pour: a_spellPhrase."
(Note: the astute reader will have noticed that this is not really a tomcat message, and
rather a Solr webapp application message; I just added it because it shows that "not
tomcat" translations are not so bad either..)
(which, incidentally, opens up another possibly interesting aspect : if such a suggested
mechanism was integrated in tomcat, it might even be able to translate, on-the-fly,
applications-generated messages, and not only tomcat's own, and at little additional
effort. How's that ?)
"INFO: start
commit(optimize=false,waitFlush=true,waitSearcher=true,expungeDeletes=false)"
--> "INFO: commencer à valider (optimiser = false, waitFlush = true, waitSearcher = true,
expungeDeletes = false)"
(I tried this one, because it looked like a perfect possibility for the translator to go
badly wrong; but it seems to do pretty well, actually).
"INFO: Server startup in 769 ms"
--> "INFO: démarrage du serveur en 769 ms"
I'm running out tomcat logfile error messages to try with..
But I think that the above kind of speaks for itself, doesn't it ?
I did not "re-touch" any of the above translations, just copied and pasted them
in 'as is'.
One aspect which I find interesting also : it apparently does not even attempt to
translate elements like class names or parameters, which is in fact quite nice in the
present case.
After seeing those, I must also confess a certain scepticism related to previous remarks
here from people having tried this before and being very disappointed. But maybe it was
quite a long time ago, that they really tried..
Note : it is not that I think that all these translations are perfect. I am just thinking
of all the effort that went into the recent POEditor translations, and all the future
efforts that will have to go into maintaining these translations for future versions of
tomcat, if we want them to remain accurate and relevant.
There were, as of yet, something like 2500 messages to translate, of which a good number
seem almost duplicates of others.
As additional development goes into tomcat, new messages will appear, which will need to
be translated to n languages, and probably a number of existing messages will become
obsolete (but will still stay in the list).
I don't really know if it would be possible to integrate some Google-translate-like code
into tomcat; but if it were possible, it seems to me that the rewards in terms of future
time /not spent/ would be largely worth the effort.
And if one thinks of possibly generalising this to other Apache projects ..
Maybe also, this does not have to be really "integrated" into tomcat. Think of a webapp,
manager-like, which you point to a tomcat logfile and tell "I want this in French, now".
Given the underlying translation "technology", and given that parsing Apache logfiles
should already have some existing code for it too..
How many times did I prefix a command with LANG=C to obtain a message I can
search on
Google ?
More than the finger count of all subscribers of this list, I guess...
I thought the same way as André when starting to translate strings, but I was
both happy
to find a way to help a bit the project.
If this kind of translation might not be most useful, translating manuals
seems, however,
more useful.
Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
