On Thu, Nov 8, 2018 at 5:30 PM Emmanuel Bourg <ebo...@apache.org> wrote: > > Le 08/11/2018 à 15:47, Mark Thomas a écrit : > > > is that a reason to drop attempts to provide i10n or > > is it an indication we aren't doing nearly enough? > > We can always do more, but considering our limited resources I think > it's wise to focus first on the most important areas (ie. messages > displayed in web pages vs internal log messages).
I think we should be focused on helping non-English speaking volunteers so that can easily help the community and themselves with translations. We don't have to do more by ourselves. I used to contribute translated Java resource bundle files to some projects such as Wicket, Jetspeed-2, ... I had to manually escape unicode strings for my Korean translation resource files until I found a nice GUI tool which escapes those automatically and shows an integrated view for different languages, missing keys, etc. If there's a good tool support somehow (perhaps like what Mark is trying with) and we say we're willing to take nice translation contributions, it could be a big help. I have not seen projects yet doing that. > > > > Seriously, we (well, those in the community that speak French > > fluently - not me) could look to improve those. > > FTR I did start working on the French translation for jasper this summer > but I got dragged to other duties. When looking around the other > resource bundles I really wondered if it made sense to translate very > technical messages though. I don't personally think there is a big difference in general between non-technical translations and tech-oriented translations once somethings are translated. For example, I translated the HelloWorldPortlet for Apache Portals before. Event "Hello, World!" was not easy to translate. ;-) "안녕, 세계여!" I see the point though: when very specific tech terms are translated without understanding the architecture/design/tech context, it could be misleading. I admit I did that many times before. But I think it's about quality issue we can probably improve collectively somehow -- like Wikipedia does -- with easy tooling and support. So, I like Mark's idea of option for admins to drop translation messages somehow, switching to English version for example. If it is easily doable, it could be a good option for both ends. > > > > 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. > > If the translations were nearly complete and of good quality I would > definitely not suggest dropping them. Yet, I think I'd still configure > Tomcat to run in English instead of French because I'm used to the > English terminology. I've just searched on a Korean portal site (e.g, www.daum.net) with Tomcat errors in Korean. I hit many. Someones help others interpreting the English messages. All of them are developers. So, I see values providing translated internal messages as well. > > > > 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. > > I don't think rearranging the JARs is necessary, it isn't difficult to > run Tomcat with a different locale. I'm more concerned about the > maintenance burden and the actual value vs the time invested. Changing system locale sometimes affects application's behavior, whether it's right or not, in some cases. If it's easy enough, rearranging ability might be more flexible and safer, IMHO. Kind regards, Woonsan > > Emmanuel Bourg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
