-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 André,
On 11/27/18 06:01, André Warnier (tomcat) wrote: > 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. I would argue that is an exercise in democratization: Tomcat can be a project that is actually accommodating to its users (administrators, programmers, etc.) instead of being hostile by using log messages that are unreadable. Note that Java itself has error messages translated into non-English languages for this very reason. Is there a huge between "io error" and "erreur d'entrée / sortie"? Not really. But I know that if I saw an error message in French, it would be a lot more difficult for me to do my job. > 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. The worst part of the above is that, in order to find the code that contains the error (if you were able to competently read the code), you have to do this: $ find . -type f -print0 | xargs -0 grep 'Could not find the main class: org.apache.catalina.startup.Bootstrap. Program will exit.' Then, finding that no files are found, I have to search for a part of it : $ find . -type f -print0 | xargs -0 grep 'Could not find the main class: ' Again, no results. Maybe a bad example. How about this one? $ find . -type f -print0 | xargs -0 grep 'Unexpected end of stream while reading opening client preface byte sequence.' ./java/org/apache/coyote/http2/LocalStrings.properties:connectionPreface Parser.eos=Unexpected end of stream while reading opening client preface byte sequence. Only [{0}] bytes read. Hmm... okay, it's in a properties file. Maybe that gets used in a source file? Let's search for that bundle key: $ find . -type f -print0 | xargs -0 grep 'connectionPrefaceParser.eos' ./output/classes/org/apache/coyote/http2/LocalStrings_fr.properties ./output/classes/org/apache/coyote/http2/LocalStrings.properties ./java/org/apache/coyote/http2/LocalStrings_fr.properties ./java/org/apache/coyote/http2/LocalStrings.properties LOL, another good example: the bundle key isn't used anywhere. But the point is that locating error messages now requires two step: find the resource bundle key, then look it up in the code. I'm not sure how to make that any better. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv+5WcACgkQHPApP6U8 pFjdAg/+KaQmmtd+VblWRI+zhTcVOPu/OSeBHruVOXPnZ0RhnnVGS5xVciU8XJtq Ppl7UWDs9oN24Qrj3Tzf/Vqai0DtqF/JxyIjqc/Q/1YjDVCTZZz57w/1b2fbzTGS fNm7I7kByt18lOVdlDgymXDSY2orGsddAvp5Sqku9lrpeyv27nB/lTBThQKxwLQc 1FZ8h0PZ835CRvs8jmIR5Zp+dsbh3b64FS2oD5VSkrqX0/Rvn4+bkLycPGNwK6Lc JzkGCPTIyiI/ZJObTzb3LR/pIUiBbKUKMokReB2Ohmi9JNrKpfefvJI43xGYXLCx Aa1dZVhWoE5ipOfRMWNjmN6g9MFWAwyAdmfANFxZnwbzV3LKwGHUgqIUodilLZKs TfHd7TbQSWzrszWBZunxEK0nkUNO/dI5Jzp7/dUARDVrewaJqgDS2XjayYlPrYHD m4prHK3i5xkMr2t8HMiKnCfGayvZglgoITyH0fjyT9j0BX4M8LdT36Qa6rfUq7bd UI9kSmQB03MKzVyA3fuYiKMjqYmTeqs74w2L1+eNjx7o9RqsdCwggAptKdOldHCP 0v2hC1JQSGmYkZUsksdxYtxfx9WT/GfEQN1XMC7wUrjPz1hRCNZWP8sTcnDeNZm/ 1w6UaSh51QaztPfjNuDPiFOFlTP5lFso9WfyfWs+0Ckkt4hViw0= =q3Tj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
