Hi to all. Im thinking going to work on "switch" code now "full" implemented in Inkscape but without GUI. Tav give me help on it.
I have a idea on how to get working but have questions. Im focused on languaje selector but maybe im wrong, maybe need a full "switch" GUI with "requiredFeatures", "requiredExtensions" and "systemLanguage" conditional processing attributes.
Realy Im not sure if "requiredFeatures" and "requiredExtensions" are useful to handle on Inkscape or maybe is better for use on the XML editor or raw SVG editing for the moment.
In my mind, with language only point of view, I need a object dialog method to redraw a "switch", and a language -or "switch"- widget to: * Add multilenguage title and desc * Switch all "switches" to one lang * Add lang to a "switch". Global? * Remove a lang * Insert selected element to a new "switch" in the default lang. * Handle more Aria atributes?
By the way, about "switches" in webpages with "systemLanguage" conditional processing attribute, whats the best way to user based switch a lang? We need a JS hack?
Now im very bussy whith my payed work but hope can take some time to this proyect but sure not as dedicated as previously :(
Regards, Jabier.
Glad to know you're still working on this Jabier,
Some comments:
Realy Im not sure if "requiredFeatures" and "requiredExtensions" are
useful to handle on Inkscape or maybe is better for use on the XML editor or raw SVG editing for the moment.
I would say that the requiredFeatures/extensions attributes are not useful. They were not very well defined in the original SVG specs, and are inconsistently implemented in browsers.
In my mind, with language only point of view, I need a object dialog method to redraw a "switch", and a language -or "switch"- widget to: * Add multilenguage title and desc * Switch all "switches" to one lang * Add lang to a "switch". Global? * Remove a lang * Insert selected element to a new "switch" in the default lang. * Handle more Aria atributes?
When *displaying* content, you only use one language at a time for the whole graphic. So for the user interface, you need a single option to switch between languages. I think it would make the most sense to put it within the "View" menu, to make it clear that you are not changing the document, you are changing the way you look at the document.
For defining the language alternatives, I think for a start it would be easiest to focus on switching individual text elements or individual title/desc elements. Allowing switches to make large scale changes to the graphics and layout would probably cause to much complication.
So the place to start would be the object properties dialog (for title/desc) and the text properties dialog. Things you would need:
- A drop-down list to declare the language of the content. - An "Add language" button which inserts another text field & language drop-down - If there are more than one languages, some sort of radio-button option for indicating which one is the default.
The following things would be nice extras, but aren't essential:
- Make the language selection a two-part drop down for main language (English, Spanish) versus country code variation (Canadian English vs US English vs UK English vs any English) - A way to re-order the languages. The browser will use the first language that matches one of the user's preferences, so the order matters.
Not that the way for expressing the default in the XML is different: for title/desc, the first option is default. It will also be used if the browser does not support the new SVG 2 language switching feature (Right now, I don't think any browser supports it!). For <switch>, the last option is the default, and it cannot have a "systemLanguage" attribute (although it should still have a xml:lang attribute).
Quick demo of the different syntax. The English version is the default, but if your browser is set to use Spanish or French, you should see the visible text in that language. Let me know if you find a browser that also switches the tooltip!
http://fiddle.jshell.net/rzz2ac4g/1/
By the way, about "switches" in webpages with "systemLanguage" conditional processing attribute, whats the best way to user based switch a lang? We need a JS hack?
Yes, currently there would need to be a JS hack to allow the user to see a different language without having to change their browser language settings. You would need to change the DOM to re-order the elements and remove the systemLanguage attribute.
Now im very bussy whith my payed work but hope can take some time to this proyect but sure not as dedicated as previously :(
I'm pretty sure everyone understands this!
I also glad to hear you Amelia. I have a boring problem. Think the lenguage settings is take by the list on prefered language list on the browser. On iceweasel this link to a SVG file work ok. http://upload.wikimedia.org/wikipedia/commons/e/e1/SystemLanguage.svg
But if put it into a HTML file the switch not work http://fiddle.jshell.net/0okbt4oq/
This happends in your browser?
About your mail:
El mar, 19-05-2015 a las 13:31 -0600, Amelia Bellamy-Royds escribió:
Glad to know you're still working on this Jabier,
Some comments:
Realy Im not sure if "requiredFeatures" and "requiredExtensions" are
useful to handle on Inkscape or maybe is better for use on the XML editor or raw SVG editing for the moment.
I would say that the requiredFeatures/extensions attributes are not useful. They were not very well defined in the original SVG specs, and are inconsistently implemented in browsers.
In my mind, with language only point of view, I need a object dialog method to redraw a "switch", and a language -or "switch"- widget to: * Add multilenguage title and desc * Switch all "switches" to one lang * Add lang to a "switch". Global? * Remove a lang * Insert selected element to a new "switch" in the default lang. * Handle more Aria atributes?
When *displaying* content, you only use one language at a time for the whole graphic. So for the user interface, you need a single option to switch between languages. I think it would make the most sense to put it within the "View" menu, to make it clear that you are not changing the document, you are changing the way you look at the document.
Ok I agree but to me is more useful: View->Language Dialog, not sure if i can add elements to the view menu without restart.
For defining the language alternatives, I think for a start it would be easiest to focus on switching individual text elements or individual title/desc elements. Allowing switches to make large scale changes to the graphics and layout would probably cause to much complication.
Not sure, I think we can use only one "group" element for each switch stament
So the place to start would be the object properties dialog (for title/desc) and the text properties dialog. Things you would need:
- A drop-down list to declare the language of the content.
- An "Add language" button which inserts another text field & language
drop-down
- If there are more than one languages, some sort of radio-button option
for indicating which one is the default.
Maybe the default is the original/start content? Because default not have lang
The following things would be nice extras, but aren't essential:
- Make the language selection a two-part drop down for main language
(English, Spanish) versus country code variation (Canadian English vs US English vs UK English vs any English)
Im thinking in a input text widget for free write of each new lang because a systemLanguage can handle multiples langs, also not sure if the lang country code variation has a standar because i usualy see in spain "es-ES" but in iceweasel mark it as "es-es" -and "es" only is not fired so maybe for full compatibility we need a long list of langs for each switch stament
- A way to re-order the languages. The browser will use the first
language that matches one of the user's preferences, so the order matters.
This is the first text i write. If the browser open a SVG match orderer, if is inluded onto a webpage, no. But this need to be fixed by browsers, anyway reorder it is a option like you say better than nothing.
Not that the way for expressing the default in the XML is different: for title/desc, the first option is default. It will also be used if the browser does not support the new SVG 2 language switching feature (Right now, I don't think any browser supports it!). For <switch>, the last option is the default, and it cannot have a "systemLanguage" attribute (although it should still have a xml:lang attribute).
Quick demo of the different syntax. The English version is the default, but if your browser is set to use Spanish or French, you should see the visible text in that language. Let me know if you find a browser that also switches the tooltip!
I dont see tooltip also viewing the svg direcly on browser
By the way, about "switches" in webpages with "systemLanguage" conditional processing attribute, whats the best way to user based switch a lang? We need a JS hack?
Yes, currently there would need to be a JS hack to allow the user to see a different language without having to change their browser language settings. You would need to change the DOM to re-order the elements and remove the systemLanguage attribute.
OK
Now im very bussy whith my payed work but hope can take some time to this proyect but sure not as dedicated as previously :(
I'm pretty sure everyone understands this!
:)
Regards, Jabier.
Which browser and OS are you using that switches the SVG file but not the SVG within HTML? It works for me in Chrome, Firefox, and Internet Explorer on Windows.
(As mentioned, the tooltips don't switch yet. That is something new for SVG 2.)
On your other points:
- You're right, using a dialog probably makes more sense then a sub-menu with all the language options. The list of languages could get very long. But you would open the dialog from the "View" menu.
- The issue of capitalization and language codes is a good point. Language tags are *supposed* to be case-insensitive, according to the document referenced from the SVG specs ( http://www.ietf.org/rfc/bcp/bcp47.txt). But...
- In both Firefox and Chrome, the language code has to be all lowercase. IE accepted either. - In Firefox and Internet Explorer, the country code works in either upper or lowercase. In Chrome, I couldn't get a language with country-code to work with any captitalization.
- Yes, you can use a single <switch> to switch between groups. When I said it was too complicated, I meant from the User Interface side, not from the SVG/XML side. But if you can come up with a good UI, great!
- Even if the default language does not have a systemLanguage attribute, or even if the user isn't switching languages at all, we should still ask for language, and use xml:lang to declare it, for accessibility reasons.
- But yes, it makes sense to use the first language they typed as the default, unless they set it to something else.
Best, Amelia
Hi Amelia. Im using iceweasel a debian "fork" of firefox. The previous JSFRIDGE is wrong: here is http://fiddle.jshell.net/q56sj6kg/ The direct SVG view as a reminder is http://upload.wikimedia.org/wikipedia/commons/e/e1/SystemLanguage.svg
My lang browser preferences are: FR ES EN Viewing direcly the SVG[1] i see "FR" Viewing same file onto a HTML[2] file see "EN"
In Chromium both show as "EN"
[1]http://fiddle.jshell.net/q56sj6kg/ [2]http://upload.wikimedia.org/wikipedia/commons/e/e1/SystemLanguage.svg
All the best, Jabier.
I played around a little more with my language settings, and got the same result as you.
On Chrome, the SVG always uses the language I have set for the interface (e.g., the language used for the browser menus and dialogs) regardless of the order of preferred languages for content. This also probably explains why Chrome wasn't matching any country codes.
I have filed a bug report with Chromium:
- https://code.google.com/p/chromium/issues/detail?id=490140
In Firefox (and iceweasel), I'm not sure why there is a difference between SVG and HTML. Within SVG, the "allowReorder" attribute (which is not in SVG, but is in SMIL) is really important. Without it, Firefox follows the specs literally and uses the first language option in the document that matches *any* of the users preferred language. Try changing the order of the languages so that "es" is before "en", and see what happens. Here is more about that:
- https://bugzilla.mozilla.org/show_bug.cgi?id=936517
However, the "allowReorder" attribute seems to be ignored in HTML. I've filed a bug (& am hoping Robert Longson jumps on it, he's pretty good about fixing these things!):
- https://bugzilla.mozilla.org/show_bug.cgi?id=1166753
I will make a note to update the SVG2 specs to be more clear about using user preferences and to include the "allowReorder" attribute.
It is all a little disappointing. We can still go ahead with making it work in Inkscape, but we can't rely on it always having a useful result in browsers.
A feature that we probably want to have in Inkscape is the ability to export the SVG in a specific language, instead of with switches. That way, the author could have a single multilingual file for editing, but could create files for the web or printing that always display a specific way, without having to worry about browser differences.
Best, Amelia
On 20 May 2015 at 02:57, Jabier Arraiza <jabier.arraiza@...2893...> wrote:
Hi Amelia. Im using iceweasel a debian "fork" of firefox. The previous JSFRIDGE is wrong: here is http://fiddle.jshell.net/q56sj6kg/ The direct SVG view as a reminder is http://upload.wikimedia.org/wikipedia/commons/e/e1/SystemLanguage.svg
My lang browser preferences are: FR ES EN Viewing direcly the SVG[1] i see "FR" Viewing same file onto a HTML[2] file see "EN"
In Chromium both show as "EN"
[1]http://fiddle.jshell.net/q56sj6kg/ [2]http://upload.wikimedia.org/wikipedia/commons/e/e1/SystemLanguage.svg
All the best, Jabier.
On Wed, 20 May 2015 08:51:16 -0600 Amelia Bellamy-Royds <amelia.bellamy.royds@...400...> wrote:
I played around a little more with my language settings, and got the same result as you.
On Chrome, the SVG always uses the language I have set for the interface (e.g., the language used for the browser menus and dialogs) regardless of the order of preferred languages for content. This also probably explains why Chrome wasn't matching any country codes.
I have filed a bug report with Chromium:
In Firefox (and iceweasel), I'm not sure why there is a difference between SVG and HTML. Within SVG, the "allowReorder" attribute (which is not in SVG, but is in SMIL) is really important. Without it, Firefox follows the specs literally and uses the first language option in the document that matches *any* of the users preferred language. Try changing the order of the languages so that "es" is before "en", and see what happens. Here is more about that:
However, the "allowReorder" attribute seems to be ignored in HTML. I've filed a bug (& am hoping Robert Longson jumps on it, he's pretty good about fixing these things!):
I will make a note to update the SVG2 specs to be more clear about using user preferences and to include the "allowReorder" attribute.
It is all a little disappointing. We can still go ahead with making it work in Inkscape, but we can't rely on it always having a useful result in browsers.
A feature that we probably want to have in Inkscape is the ability to export the SVG in a specific language, instead of with switches. That way, the author could have a single multilingual file for editing, but could create files for the web or printing that always display a specific way, without having to worry about browser differences.
Dear Jabier & Amelia,
Do either of you have experience with DocBook http://www.docbook.org/ ? This is a widely used documentation system system into which SVG documents are commonly embedded. DocBook supports multiple languages on most XML elements and you might benefit from reading about the approach they use to process documents. Of particular interest is the chapters on graphics and languages DocBook XML: The Complete Guide which is available via that website.
I am sorry for the noise if you know about this already.
Yours,
Is.
Dear Isobel,
I knew that you could put SVG in docbook, but I wasn't really thinking about how that might impact language switching. I also had not thought about using XSL as a language switch, although it is a natural use of that technology.
I don't think there should be any conflict with using SVG <switch> inside docbook, since this is a standard SVG element -- the question is whether your docbook processor has implemented support for it! If you want to test out any tools with Jabier's sample graphic, I'd love to hear the results.
The switching for <title> and <desc> elements might interact with docbook & XSL switching, since they all use the basic lang attribute. However, I don't think it would be a conflict, it would just mean that the language switching might happen at a different stage (when generating the styled Book XML instead of when rendering the SVG to an accessible form).
If a DocBook processor doesn't support SVG <switch>, the other option would be to generate separate, complete versions of the SVG, and include them as alternate media objects with docbook language switchers. Which is another use case for having an "Export in Language" option for Inkscape.
Thanks for the input, Amelia
On 21 May 2015 at 01:54, Isobel Knowles <ik5@...2950...> wrote:
Dear Jabier & Amelia,
Do either of you have experience with DocBook http://www.docbook.org/ ? This is a widely used documentation system system into which SVG documents are commonly embedded. DocBook supports multiple languages on most XML elements and you might benefit from reading about the approach they use to process documents. Of particular interest is the chapters on graphics and languages DocBook XML: The Complete Guide which is available via that website.
I am sorry for the noise if you know about this already.
Yours,
Is.
If a DocBook processor doesn't support SVG <switch>, the other option would be to generate separate, complete versions of the SVG, and include them as alternate media objects with docbook language switchers. Which is another use case for having an "Export in Language" option for Inkscape.
I dont like this option too much :( -maybe as a extra option but too much files to use for a doc...- I like more only one file SVG multilenguage, maybe switched by the moment by JavaScript removing "systemLanguage" values while it dont reneder ok in enought browsers. One question more, if this go live on SVG: http://www.w3.org/TR/2009/WD-SVGParamPrimer-20090430/ Can be usabled into a switch selector?
Regards, Jabier
Don't expect SVG Parameters to happen in the way that document describes. However, maybe there will be something new that can control languages -- although, I don't how it would fit. The rest of the <switch> is all about whether the browser can do something or not. So there is no choice. But for language, there should be choice.
Amelia BR
On 24 May 2015 at 09:25, Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...> wrote:
One question more, if this go live on SVG: http://www.w3.org/TR/2009/WD-SVGParamPrimer-20090430/ Can be usabled into a switch selector?
Regards, Jabier
Hi Amelia. A lot of time...
I read your last mail about creating diferent SVG for each language defined in a multilenguaje SVG, I dont like very much this, I like more a unique multilenguaje SVG.
With the news about languaje support the proyect become less interesting to me for the moment. Maybe is better wait wath happends in SVG/Browsers with lenguage switches in SVG.
All the best, Jabier.
El mar, 19-05-2015 a las 23:44 +0200, Jabiertxo Arraiza Cenoz escribió:
I also glad to hear you Amelia. I have a boring problem. Think the lenguage settings is take by the list on prefered language list on the browser. On iceweasel this link to a SVG file work ok. http://upload.wikimedia.org/wikipedia/commons/e/e1/SystemLanguage.svg
But if put it into a HTML file the switch not work http://fiddle.jshell.net/0okbt4oq/
This happends in your browser?
About your mail:
El mar, 19-05-2015 a las 13:31 -0600, Amelia Bellamy-Royds escribió:
Glad to know you're still working on this Jabier,
Some comments:
Realy Im not sure if "requiredFeatures" and "requiredExtensions" are
useful to handle on Inkscape or maybe is better for use on the XML editor or raw SVG editing for the moment.
I would say that the requiredFeatures/extensions attributes are not useful. They were not very well defined in the original SVG specs, and are inconsistently implemented in browsers.
In my mind, with language only point of view, I need a object dialog method to redraw a "switch", and a language -or "switch"- widget to: * Add multilenguage title and desc * Switch all "switches" to one lang * Add lang to a "switch". Global? * Remove a lang * Insert selected element to a new "switch" in the default lang. * Handle more Aria atributes?
When *displaying* content, you only use one language at a time for the whole graphic. So for the user interface, you need a single option to switch between languages. I think it would make the most sense to put it within the "View" menu, to make it clear that you are not changing the document, you are changing the way you look at the document.
Ok I agree but to me is more useful: View->Language Dialog, not sure if i can add elements to the view menu without restart.
For defining the language alternatives, I think for a start it would be easiest to focus on switching individual text elements or individual title/desc elements. Allowing switches to make large scale changes to the graphics and layout would probably cause to much complication.
Not sure, I think we can use only one "group" element for each switch stament
So the place to start would be the object properties dialog (for title/desc) and the text properties dialog. Things you would need:
- A drop-down list to declare the language of the content.
- An "Add language" button which inserts another text field &
language drop-down
- If there are more than one languages, some sort of radio
-button option for indicating which one is the default.
Maybe the default is the original/start content? Because default not have lang
The following things would be nice extras, but aren't essential:
- Make the language selection a two-part drop down for main
language (English, Spanish) versus country code variation (Canadian English vs US English vs UK English vs any English)
Im thinking in a input text widget for free write of each new lang because a systemLanguage can handle multiples langs, also not sure if the lang country code variation has a standar because i usualy see in spain "es-ES" but in iceweasel mark it as "es-es" -and "es" only is not fired so maybe for full compatibility we need a long list of langs for each switch stament
- A way to re-order the languages. The browser will use the
first language that matches one of the user's preferences, so the order matters.
This is the first text i write. If the browser open a SVG match orderer, if is inluded onto a webpage, no. But this need to be fixed by browsers, anyway reorder it is a option like you say better than nothing.
Not that the way for expressing the default in the XML is different: for title/desc, the first option is default. It will also be used if the browser does not support the new SVG 2 language switching feature (Right now, I don't think any browser supports it!). For <switch>, the last option is the default, and it cannot have a "systemLanguage" attribute (although it should still have a xml:lang attribute).
Quick demo of the different syntax. The English version is the default, but if your browser is set to use Spanish or French, you should see the visible text in that language. Let me know if you find a browser that also switches the tooltip!
I dont see tooltip also viewing the svg direcly on browser
By the way, about "switches" in webpages with "systemLanguage" conditional processing attribute, whats the best way to user based switch a lang? We need a JS hack?
Yes, currently there would need to be a JS hack to allow the user to see a different language without having to change their browser language settings. You would need to change the DOM to re-order the elements and remove the systemLanguage attribute.
OK
Now im very bussy whith my payed work but hope can take some time to this proyect but sure not as dedicated as previously :(
I'm pretty sure everyone understands this!
:)
Regards, Jabier.
participants (4)
-
Amelia Bellamy-Royds -
Isobel Knowles -
Jabier Arraiza -
Jabiertxo Arraiza Cenoz