On 03/17/2010 08:30 PM, Amos Jeffries wrote:
> If anyone has ideas towards this please add.
>
> As you probably know, I'm slowly rolling translation of texts across the
> Squid code base.
> I've now done the easy bits (error pages and manuals). For 3.2 I'd like to
> go a bit further.
>
> The types of program strings I've identified so far are:
>
> * Strings Squid adds to the error pages (month names, OS messages, other
> stuff?)
>
> * Month names Squid adds to access.log
>
> * Warning: headers ??
Sounds good.
> * administrative debugs() messages (WARNING etc)
> I don't believe we want to go deeper than the level 1 stuff being shown
> to administrators.
>
> We will also face the problem of;
> * if cache.log stuff gets translated and someone reports an error how do
> we read it ourselves?
> It might involve adding some context code to the output. I hate dealing
> with those, but to to make the major cache.log text localized we may
> require it.
> ... or it may involve dumping the text twice (English + Foo versions)
What is the primary motivation behind "translating" cache.log? Do we get
a lot of complaints from admins that cannot understand the meaning of
cache.log warnings because of the language barrier? Or do we think that
we do not get a lot of complaints because of the language barrier to
write a complaint in English?
In many cases, the warning message is marginally useful without the
ability to google for it and find relevant discussions/advice, most of
which are in English.
Perhaps we can add unique message IDs to errors and warnings (which is a
required step anyway) but keep the rest of it simple and informal?
I am not against the idea as such. I am just surprised you want to spend
your valuable cycles on it.
Thank you,
Alex.
Received on Thu Mar 25 2010 - 15:02:14 MDT
This archive was generated by hypermail 2.2.0 : Thu Mar 25 2010 - 12:00:11 MDT