Hi,
I am currently planning to add support for internationalized (translatable) SVG documents. And I guess it is better to share my thoughts before going deep to implementation, so everyone will be aware of my plans and maybe someone will criticize or adjust my plans. My current plan is to implement this in steps: * 1 step - <switch> support. I already tested prototype of semi-working switch element support, but there still some work to do. Currently switch element works just like <g>, but I will make it work according to SVG standard - to render only first element which conditional properties evaluate to true (I will implement support for "systemLanguage" property for a start, which will evaluate to true if property is not set or contains current document language). I plan to make SPSwitch a subclass of SPGroup, so user can enter switch element (turn it into a temporery layer, which will show all contained items, not just first) * 2 step - bitmap export by language (ability to define language to use for <switch> in command line) * 3 step - export/import of texts. Import will also create <switch> elements if not already created * 4 step - UI support for language. I don't know for sure how it should be implemented, but I guess there should be a menu item to turn text to switch ("Make translatable") and language combo in Text dialog (to be shown only if switch is selected)
Anyway, I'm open for there are any suggestions or objections.
Andrius
On Apr 6, 2006, at 10:39 PM, Andrius Ramanauskas wrote:
Hi,
I am currently planning to add support for internationalized (translatable) SVG documents. And I guess it is better to share my thoughts before going deep to implementation, so everyone will be aware of my plans and maybe someone will criticize or adjust my plans. My current plan is to implement this in steps:
- 1 step - <switch> support. I already tested prototype of semi-
working switch element support, but there still some work to do. Currently switch element works just like <g>, but I will make it work according to SVG standard - to render only first element which conditional properties evaluate to true (I will implement support for "systemLanguage" property for a start, which will evaluate to true if property is not set or contains current document language). I plan to make SPSwitch a subclass of SPGroup, so user can enter switch element (turn it into a temporery layer, which will show all contained items, not just first)
See if you can track down any info on proposed changes to <switch> for SVG 1.2. I believe there was possibly quite a bit in there. I seem to recall something about it applying to more areas...
It would be good if whatever you coded at least could leave room for extending to 1.2 as needed.
You also might want to look at more than just language as you do that. One thing we want to be able to do is support different "target" platforms... SVG Tiny, specific browsers, Phones, PDA's, etc... so their impact on <switch> would be something to at least keep in mind.
On 4/7/06, Andrius Ramanauskas <knutux@...400...> wrote:
- 1 step - <switch> support. I already tested prototype of semi-working
switch element support, but there still some work to do. Currently switch element works just like <g>, but I will make it work according to SVG standard - to render only first element which conditional properties evaluate to true (I will implement support for "systemLanguage" property for a start, which will evaluate to true if property is not set or contains current document language).
And the current document language is defined where? Taken from the OS and probably overridden in document properties?
I plan to make SPSwitch a subclass of SPGroup, so user can enter switch element (turn it into a temporery layer, which will show all contained items, not just first)
Making it a subclass of group is OK, but I don't see how this will let you see all variants just by entering it - only by "ungrouping" it, i.e. removing the switch. You will need to implement the non-destructive "see all" method for switch separately.
Even then, I'm reluctant to approve this because it will violate our "correct rendering of SVG" principle. For example a user may give a command to see all in a switch and leave it in that state, forgetting to undo this, in which case our display of that SVG document will remain different from e.g. Batik.
I think the "see all" functionality is still doable, we just need to invent a good unambiguous UI for it.
The rest of your plan looks good. By the way, thanks also for your work on clipping/masking - it's much appreciated!
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 4/7/06, bulia byak <buliabyak@...400...> wrote:
<..> And the current document language is defined where? Taken from the OS and probably overridden in document properties?
Yes, my initial plans were to use document properties, if document properties do not define a language, use OS language
<..> Making it a subclass of group is OK, but I don't see how this will let you see all variants just by entering it - only by "ungrouping" it, i.e. removing the switch. You will need to implement the non-destructive "see all" method for switch separately.
I thought to implement it by rendering switch differently if it is in layer mode, but you are right, it will not be intuitive that way. I will try to find some other way - maybe just a submenu "Conditions" with menu items "Define conditions", "Turn group to switch" and "Turn switch to group".
Andrius
participants (3)
-
Andrius Ramanauskas -
bulia byak -
Jon A. Cruz