On Thu, Nov 8, 2018 at 3:47 PM Mark Thomas <ma...@apache.org> wrote: > On 08/11/2018 00:16, Emmanuel Bourg wrote: > > Le 07/11/2018 à 23:36, Mark Thomas a écrit : > > > >> WDYT? > > > > What about simplifying the issue by dropping the translations of the > > internal messages and retaining only the user facing messages (things > > like HTTP error messages that can appear in a normal request) ? > > That was completely unexpected. Some serious food for thought here. >
Same :D > > > I think it's worth considering because: > > - The target audience of Tomcat is mainly developers and administrators > > which are used to read English text. > > My primary concern is that it could make Tomcat less accessible to > non-native Eglish speakers. Granted all of our documentation, nearly > every message on the mailing list, issue tracker, code comments etc are > all in English but is that a reason to drop attempts to provide i10n or > is it an indication we aren't doing nearly enough? > > The irony of asking that question on a mailing list where messages are > in English hasn't escaped me. > Yes, the question is: is it ever going to be possible to use Tomcat for someone who doesn't understand english at all (since the req level is pretty low). However, whatever happens, using a string bundle should remain mandatory. > > > - The coverage of the translations is rather low. > > They tend to get done once at a point in time where they are close to > 100% and then tail of as the code is refactored and new features added. > > > - Maintaining the translations, the quality and the consistency is > > difficult and time consuming. > > There has been very little of this. I recall a big donation of Spanish > translations, the recent Russian additions and then, apart from those, > the odd typo fix here and there. My hope was that, with a tool like > POEditor, it would be easier for contributors to improve and/or add to > the translations. > > > - Sometimes the translation of the technical terms are a bit unusual and > > not as clear as the English counterpart. For example in French it isn't > > obvious that "gestionnaire de protocole" relates to ProtocolHandler > > which is an internal Tomcat concept. Other translations are even funny > > like "enrobeur de conteneur" for "wrapper container" (a pastry concept > > applied to a freight container?). This issue is so common with the > > French translation that many messages carry the English terms in > > parentheses to clarify the meaning. > > If my French was a lot better, I might just start reading the > translations to enjoy the humour. Seriously, we (well, those in the > community that speak French fluently - not me) could look to improve > those. I think it might be better to not translate class/interface names > like "ProtocolHandler", "Realm" or maybe put the translations in > brackets. As for the shipping container wrapped in pastry, I assume a > better translation is possible. > It might sound funny, but the pastry thing is correct. > > But that brings us back to your original question of whether the > translations are worth it. If (and it is a fairly big if) the > translations were mostly complete and mostly of good quality, would that > change your view? I'm thinking try and improve the translations as a > first step and, if things don't improve, then decide what to do next. > Ok for trying ! > > Removing the translations (apart from the UI) feels to be too big a step > to me. That said, I can see how they would be a hindrance rather than a > help to some. Perhaps separating the l10n JARs into user facing and > external would give more options. Admins could remove the translated JAR > for the internal messages and get those messages in English if they > prefer. Or we could ship less or even no translations for internal > messages by default and provide them as a separate download. > "apart from the UI", like the manager webapp ? It might sounds obvious, but if Tomcat is not usable by someone who doesn't understand english, then it will not add any value but only add confusing translations depending on the language configured in the user browser. Rémy
