SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0002298: i18n strings sometimes are calculated only on import (some german translation is missing) - MantisBT
MantisBT - Endian Firewall
View Issue Details
0002298Endian FirewallGUIpublic2009-10-27 13:212010-11-22 12:04
aender 
peter-endian 
normaltextalways
closedfixed 
2.3 
2.3.1 
0002298: i18n strings sometimes are calculated only on import (some german translation is missing)
Here are some things who are not translated to german:

Dashboard (Incoming traffic in KB/s (max. 6 interfaces))

Qos: Devices

Add Quality of Service Device
Device Upstream Bandwidth (kbit/s) Downstream Bandwidth (kbit/s) Actions

Also Headers in Classes and Rules

Searching for others...
No tags attached.
related to 0002507closed peter-endian emi GUI pages not working when Endian language Hungarian 
Issue History
2009-10-27 13:21aenderNew Issue
2009-10-27 15:59peter-endianNote Added: 0003158
2009-10-27 15:59peter-endianStatusnew => confirmed
2009-10-27 16:05peter-endianNote Added: 0003159
2009-10-27 16:05peter-endianTarget Version => 2.3.1
2009-10-27 16:06peter-endianSummarysome german translation is missing => i18n strings sometimes are calculated only on import (some german translation is missing)
2009-11-10 02:23peter-endianNote Added: 0003279
2009-11-10 10:52peter-endianNote Added: 0003280
2009-11-10 11:35peter-endianNote Added: 0003281
2009-11-10 13:32peter-endianNote Added: 0003282
2009-11-10 13:32peter-endianStatusconfirmed => resolved
2009-11-10 13:32peter-endianResolutionopen => fixed
2009-11-10 13:32peter-endianAssigned To => peter-endian
2009-12-11 14:33peter-endianRelationship addedrelated to 0002507
2010-11-22 12:04peter-endianStatusresolved => closed

Notes
(0003158)
peter-endian   
2009-10-27 15:59   
I think this is not missing translation, but an issue with reloading of translation data.

Quick workaround:
/etc/init.d/emi restart

Afterwards you should have the correct translations
(0003159)
peter-endian   
2009-10-27 16:05   
This happens when _(strings) are assigned to variables, for example within schemas.

The assignment happens when the function is called, which is during import of the modules. The _() function is not called anymore afterwards, since the string is already assigned.
After changing the language the function will never be called.

Maybe we need to implement a callable _ class, instead of _() as a function. Then the instance of the _ object is assigned and not the string itself.
So on every printout of _ the real value of the string will be calculated on the fly. Gettext caches pretty good, so this should not become to slow.

If the language changes, the translations are set dirty and will be recalculated, which happens then when printing a _ object.
(0003279)
peter-endian   
2009-11-10 02:23   
_() class is not enough.

Have that class now. For first, it needs a wrapper, which allows wrapper(id, domain, locale), which is necessary because __str__() does not allow more parameters.

Second, __str__() and __repr__() is not enough, to wrap to translate(), since there will be used also other methods like __mod__, __len__ and so on, so every single method need to be wrapped, which can be done with a metaclass, which wraps
every method call using translate()
-> also done and works (normally :/)

It does not work, when that wrapped type will be casted to unicode, which does genshi.

unicode(I18nString('test')) reads directly from the string representation ofthe I18nString type which is 'str' because I18nString extends 'str'. That's necessary, but causes unicode() not to use the wrapped methods, but to read directly from the original value, since the cast is used to do that in that manner.

No idea how to solve this :/
(0003280)
peter-endian   
2009-11-10 10:52   
Don't even work when I18nString extends object instead of str, since FormEncode checks for basestring, which I18nString then is not, since it is object
(0003281)
peter-endian   
2009-11-10 11:35   
Works with python2.5, where unicode() calls __str__() instead of reading the str internal variable.
-> This is a bug of python 2.4
(0003282)
peter-endian   
2009-11-10 13:32   
merged the fix of python 2.5 into our 2.4 version. it's working now