<html><body>
<p><tt><font size="2">Łukasz Jernaś <deejay1@srem.org> wrote on 10/16/2013 02:26:28 AM:<br>
<br>
> I'm still trying to wrap my head around the need for translating API<br>
> messages and log messages as IMHO it adds a lot more problems for app<br>
> developers and log analysis tools, eg. a log analysis tool would be<br>
> usable only for the locale it was developed for and break with _every_<br>
> update of the translations. As a translator myself I don't really want<br>
> to check every system in existence if it uses my messages to do some<br>
> sort analysis and often change the strings to more proper form in my<br>
> language as reviews and feedback on the translation comes in - even<br>
> though the original English string doesn't change at all.<br>
> I feel that translating mostly computer facing stuff is just crying<br>
> for bugs, weird issues popping up for users, API-s should be readable<br>
> by humans, but translating them is a bit too far in my opinion.</font></tt><br>
<br>
<tt><font size="2">The original reason I got involved with the i18n stuff in OpenStack was</font></tt><br>
<tt><font size="2">because we had a need to be able to debug issues on system running a </font></tt><br>
<tt><font size="2">non-English locale, and therefore spitting out logs of translated messages.</font></tt><br>
<tt><font size="2">This makes it extremely difficult to debug for two reasons, the inline</font></tt><br>
<tt><font size="2">messages in code are English, and if the person doing the debugging doesn't</font></tt><br>
<tt><font size="2">understand the language the logs are in, it is obviously harder to find </font></tt><br>
<tt><font size="2">issues on the system.</font></tt><br>
<tt><font size="2"> <br>
> If I get it right the Message objects are supposed to move stuff<br>
> around internally in a C/en locale, but we will still end up dropping<br>
> translated messages to computers if the don't explicitly specify the<br>
> locale which the request should use...</font></tt><br>
<br>
<tt><font size="2">Messages are designed to wrap the original inline English string, so</font></tt><br>
<tt><font size="2">that at a later time, such as outputting to a log handler or at the</font></tt><br>
<tt><font size="2">API layer when outputting an HTTP response, we can translate the </font></tt><br>
<tt><font size="2">internal string to a requested locale we may know at that time.</font></tt><br>
<tt><font size="2">The way the _() gettext function works is to translate everything</font></tt><br>
<tt><font size="2">immediately to the system locale.</font></tt><br>
<br>
<tt><font size="2">This leads to the two problems Messages is supposed to address:</font></tt><br>
<tt><font size="2"> 1. localizable messages coming out of the API will be</font></tt><br>
<tt><font size="2"> translated to the system locale (which doesn't really make sense IMO)</font></tt><br>
<tt><font size="2"> 2. log records are translated to the system locale as well, making</font></tt><br>
<tt><font size="2"> debugging issues that much more difficult on a non-English locale</font></tt><br>
<br>
<tt><font size="2">These could also be addressed by removing the original gettext </font></tt><br>
<tt><font size="2">immediate translation of log/API messages.</font></tt><br>
<br>
<tt><font size="2">Removing translation from the OpenStack server projects actually</font></tt><br>
<tt><font size="2">makes more sense to me, because, as you pointed out, they are services</font></tt><br>
<tt><font size="2">with APIs that are meant to utilized by other programs, not users</font></tt><br>
<tt><font size="2">directly. Also, there is the matter of log messages being translated,</font></tt><br>
<tt><font size="2">which makes auditing and debugging difficult, which is the primary use</font></tt><br>
<tt><font size="2">of logging facilities IMHO.</font></tt><br>
<br>
<tt><font size="2">I have been told several times that we can't remove the i18n functionality</font></tt><br>
<tt><font size="2">from the projects because some users want it still. I would be interested</font></tt><br>
<tt><font size="2">in hearing more from the users and developers that would like to keep</font></tt><br>
<tt><font size="2">the functionality around.</font></tt></body></html>