This mail is an automated notification from the bugs tracker
of the project: Savane.
/**************************************************************************/
[bugs #257] Latest Modifications:
Changes by:
Tobias Toedter <[EMAIL PROTECTED]>
'Date:
Tue 06/22/2004 at 17:18 (Europe/Berlin)
------------------ Additional Follow-up Comments ----------------------------
Yes, sort of. For examples, just see this page: On top of the page, there are some
select boxes, which indicate certain states of this bug report (e.g. Severity,
Priority, Resolution, Status).
All these select boxes make perfectly sense to be translated, but the content comes
from the SQL-Database and is therefore not recognizable by gettext.
Another option of resolving this bug (instead of duplicating all tables for every
language/locale) would be to add another column to the existing tables, named locale
(or something along these lines). It would then be possible to select the matching
entry (e.g. by adding "locale='de_DE'" to the WHERE-clause). If no such translation
exists, the function should revert to the default language and return the entry for
e.g. locale='en_US' or maybe even locale='C'.
/**************************************************************************/
[bugs #257] Full Item Snapshot:
URL: <http://gna.org/bugs/?func=detailitem&item_id=257>
Project: Savane
Submitted by: Tobias Toedter
On: Wed 02/11/2004 at 18:28
Category: Web Frontend
Severity: 2 - Ordinary
Priority: A - Later
Resolution: None
Assigned to: None
Status: Open
Release:
Planned Release:
Summary: HTML select boxes are not prepared for I18N
Original Submission: The HTML select boxes on the site are generated through an SQL
query. The returned result contains the id and the text of an item.
This way, only texts from the database are inserted into the select boxes, bypassing
gettext.
I think that the severity of this bug is ordinary (or even trivial), but the solution
seems to be a major pain in the ass.
Follow-up Comments
------------------
-------------------------------------------------------
Date: Tue 06/22/2004 at 17:18 By: toddy
Yes, sort of. For examples, just see this page: On top of the page, there are some
select boxes, which indicate certain states of this bug report (e.g. Severity,
Priority, Resolution, Status).
All these select boxes make perfectly sense to be translated, but the content comes
from the SQL-Database and is therefore not recognizable by gettext.
Another option of resolving this bug (instead of duplicating all tables for every
language/locale) would be to add another column to the existing tables, named locale
(or something along these lines). It would then be possible to select the matching
entry (e.g. by adding "locale='de_DE'" to the WHERE-clause). If no such translation
exists, the function should revert to the default language and return the entry for
e.g. locale='en_US' or maybe even locale='C'.
-------------------------------------------------------
Date: Tue 06/22/2004 at 12:59 By: yeupou
Can you give an example?
There is indeed the problem of i18n database data -- I'm afraid to think about
duplicating for each language possible the tables. Is that what you thinking of?
For detailed info, follow this link:
<http://gna.org/bugs/?func=detailitem&item_id=257>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[EMAIL PROTECTED]
https://mail.gna.org/listinfo/savane-dev
