| | | |interface Efl.Ui.I18n | | | |├ (P) mirrored | | | |├ (P) mirrored_automatic | | | |├ (P) language
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T7510 evaluate stabilization potential of efl.ui classes and dependencies | ||
| Open | None | T7845 Unstructured stabilization items | ||
| Open | None | T7849 efl.ui.text | ||
| Open | None | T7859 efl.ui.box | ||
| Open | None | T7869 efl.ui.datepicker | ||
| Open | None | T7870 efl.ui.grid | ||
| Open | None | T7873 efl.ui.image | ||
| Open | None | T7880 efl.ui.bg | ||
| Open | None | T7881 efl.ui.list | ||
| Open | cedric | T7885 efl.ui.list_view | ||
| Open | None | T7891 efl.ui.scroller | ||
| Open | None | T7893 efl.ui.slider | ||
| Open | None | T7897 efl.ui.spin | ||
| Open | None | T7899 efl.ui.table | ||
| Open | None | T7901 efl.ui.timepicker | ||
| Open | None | T7904 efl.ui.grid_item | ||
| Open | None | T7906 efl.ui.list_item | ||
| Open | None | T7905 efl.ui.item | ||
| Open | None | T7947 Efl.Ui.Anchor_Popup | ||
| Open | None | T7951 Efl.Ui.Text_Alert_Popup | ||
| Open | None | T7952 Efl.Ui.Scroll_Alert_Popup | ||
| Open | None | T7948 Efl.Ui.Alert_Popup | ||
| Open | None | T7902 efl.ui.popup | ||
| 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.