| | | |interface Efl.Ui.I18n | | | |├ (P) mirrored | | | |├ (P) mirrored_automatic | | | |├ (P) language
Description
Description
| Status | Assigned | Task | |
|---|---|---|---|
| · · · | |||
| Resolved | zmike | T7555 efl.canvas.object | |
| Open | None | T7566 efl.ui.i18n | |
| · · · |
Comment Actions
The reason i have stopped this is that i18n & l10n need some major rethoughts:
In i18n we have mixed up a few things. There is IMO no real reason to have a different language per widgets, a language is per UI, not per widget. Same could be argured for mirrored, I just don't know much about mirrored. Further more, we allow in EFL evas objects etc. to work with a mirrored state. However, the interface only works for objects which inherit properties based on a tree-like structure, pure Evas_Objects don't have them, so mirrored_automatic does not make sense on those objects.
In l10n we are saving one translation for a translatable per domain PER OBJECT. Which is wrong IMO, since once central translation database like gettext is more than enough, thus this whole interface should be a standalone object with a event replacing the translation_update function, however, i was not able to work more on it as time passed by and I had to prepare for FOSDEM.
Comment Actions
The per object support for localization might be an historic request for some weird UI support where a part of the UI was defined for a different locale that the rest. I have no idea if there is any request for this to be kept for any existing product. Also with Efl interface, the root object is always going to be an Efl.Ui.Win which will have i18n defined on, so any Efl.Canvas.Object should actually be in a tree structure now.
For l10n, I think this is done for configuration UI that only has a sub tree getting translated until the change are validated.