Ola buenas noches nomás para darle mi número de cuenta ok gracias El mié., 28 de nov. de 2018 10:58 AM, Christopher Schultz < ch...@christopherschultz.net> escribió:
> -----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 > >
