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:
On Mon, Nov 26, 2018 at 3:46 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
André,
On 11/26/18 08:35, André Warnier (tomcat) wrote:
On 26.11.2018 13:29, Rémy Maucherat wrote:
On Sat, Nov 24, 2018 at 9:48 AM Ludovic Pénet
<l.pe...@senat.fr> wrote:
Le vendredi 23 novembre 2018 à 23:51 +0100, Rémy Maucherat
a écrit :
On Wed, Nov 21, 2018 at 10:58 AM Mark Thomas
<ma...@apache.org> wrote:
- French has increased from 18% to 64% coverage
Done (well, close enough, a few tribes/ha remain) !
A single translation remains to be performed.
Jump to https://poeditor.com/join/project/NUTIjDWzrl and be
the one to complete the French translation. ;-)
Ok, you could have finished it, I was busy.
Now we can try to harmonize terms, fixes are then easy to do
with the search feature
Common ones we have right now: - "socket" (usually
untranslated or cleverly omitted): ? - "endpoint" (for
websockets, and for the Tomcat connectors, so possibly two
different terms): "point d'entrée" ?
That sounds like exactly the opposite of "endpoint" to me.
Although I must say that even in English, the vocabulary used
in some reference documents (in particular everything to do
with XML-based protocols, such as SOAP, SAML, OASIS and the
like) is sometimes mysterious and counter-intuitive. What about
"cible" here ? Or more literally, "point final" ?
I disagree.
An "endpoint" is a thing to which clients connect... an "entry
point", as Rémy suggests.
French and English constructs are the opposite in a lot of cases so
that's why I though that "point d'entrée" was pretty good, as you
stay the endpoint for the client is the "startingpoint" for the
server (but there it sounds really bad).
For "socket", "soquet" (like the piece in which you insert a
plug, or a lightbulb) sounds ok to me.
This sounds okay to me, thought I don't know French at all. :)
- "thread" (often it is untranslated elsewhere): "fil
d'exécution" ? - "membership" (that's the clustering
object): "gestionnaire de membres" ?
"Membership" refers to "le fait d'être membre", no ? "adhésion"
? (like "cluster members" -> "adhérents au cluster" (with the
appropriate French pronounciation for "cleustère") :-)
What would you call a list of people who belong to a certain
fancy club or society? That's the word that should be used,
here.
So ... In that case it would simply be "liste de membres". Which
after a quick check actually looks quite good in the context of the
Tribes strings.
I have another difficult one for Tribes: that "replicated map"
which should be ?? "structure répliquée" ? I used various terms for
that annoying one ...
I'm a bug fan of naming things what they *mean*, not what they are.
For example, seeing this in code:
Map<String,Class<?>> mapOfStringToClass = ...;
Is totally worthless from a self-documenting code perspective. This is
much better:
Map<String,Class<?>> beanImplementationClasses = ...;
or, even better from a French perspective :
Carte<Chaine,Classe<?>> classedImplementationdHaricot = ...;
;-)
I think we should do the same thing with our descriptions, here.
So, for example, the fact that it's called "replicatedMap" in English
probably doesn't matter. The "replicated" part is important. The "map"
probably isn't. It could be any collection of objects. So, "replicated
structure" seems reasonable, here.
On the other hand, when saying "something is wrong with the
MacGuffin[1]", translating the word "MacGuffin" may make things worse.
If you want to know how to look it up in the documentation and/or
code, it needs to agree with what's there. Since the code is
(nominally) in English, the term might need to be in English.
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.
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.
Now I really apologise to anyone who has already spent a great amount of donated time to
achieve the current levels of translations.
But, not to mince words, isn't this all in all and ultimately, a big waste of
time ?
And shouldn't we be looking at more efficient ways of achieving the real main goal of all
this, which is basically to make sure that, when something bad happens as a result of
using tomcat, the people in charge would get precise and understandable information about
what happened, and about where they can find more information helping them correcting the
issue ?
I'll use an example :
Suppose I'm one of these non-native-English-speakers sysadmins or developers, and I find a
message in the tomcat logs, such as :
"Could not find the main class: org.apache.catalina.startup.Bootstrap. Program will
exit."
and I do not really understand what it says.
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 ?
And if nowadays Google can do that, not only for tomcat but for a host of fields and
languages, should it not be possible to integrate some of this logic directly into tomcat,
which after all needs a very limited subset of vocabulary to achieve something equivalent
? Or, considering the above examples, should we even bother ?
Voilà. I do not particularly like to shock for the sake of it. But I feel that sometimes,
someone has to shake the tree to bring back a sense of reality (or, in this case, gravity
?) in this geek world.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
