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
|Anonymous | Login||2022-06-28 19:30 UTC|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002298||Endian Firewall||GUI||public||2009-10-27 13:21||2010-11-22 12:04|
|Target Version||2.3.1||Fixed in Version|
|Summary||0002298: i18n strings sometimes are calculated only on import (some german translation is missing)|
|Description||Here are some things who are not translated to german:|
Dashboard (Incoming traffic in KB/s (max. 6 interfaces))
Add Quality of Service Device
Device Upstream Bandwidth (kbit/s) Downstream Bandwidth (kbit/s) Actions
Also Headers in Classes and Rules
Searching for others...
|Tags||No tags attached.|
I think this is not missing translation, but an issue with reloading of translation data.
Afterwards you should have the correct translations
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.
_() 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 :/
|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|
Works with python2.5, where unicode() calls __str__() instead of reading the str internal variable.
-> This is a bug of python 2.4
|merged the fix of python 2.5 into our 2.4 version. it's working now|
|2009-10-27 13:21||aender||New Issue|
|2009-10-27 15:59||peter-endian||Note Added: 0003158|
|2009-10-27 15:59||peter-endian||Status||new => confirmed|
|2009-10-27 16:05||peter-endian||Note Added: 0003159|
|2009-10-27 16:05||peter-endian||Target Version||=> 2.3.1|
|2009-10-27 16:06||peter-endian||Summary||some german translation is missing => i18n strings sometimes are calculated only on import (some german translation is missing)|
|2009-11-10 02:23||peter-endian||Note Added: 0003279|
|2009-11-10 10:52||peter-endian||Note Added: 0003280|
|2009-11-10 11:35||peter-endian||Note Added: 0003281|
|2009-11-10 13:32||peter-endian||Note Added: 0003282|
|2009-11-10 13:32||peter-endian||Status||confirmed => resolved|
|2009-11-10 13:32||peter-endian||Resolution||open => fixed|
|2009-11-10 13:32||peter-endian||Assigned To||=> peter-endian|
|2009-12-11 14:33||peter-endian||Relationship added||related to 0002507|
|2010-11-22 12:04||peter-endian||Status||resolved => closed|
|Copyright © 2000 - 2012 MantisBT Group|