On Mar 19, 2009, at 12:06 PM, ext Marcos Caceres wrote:
On Thu, Mar 19, 2009 at 4:52 PM, Andrew Welch
andrew.j.we...@gmail.com wrote:
That's exactly what I was talking about when I said even thought
the XML i18n
guidelines say it's bad practice,'.
Ahh very sorry, I just saw the email
In the context of the discussion about having a mandatory config file, I
proposed to simplify matters even further and have just one config file, with
the note that this proposal could be ignored in the interest of time and/or
effort. There are pros and cons to both approaches, as Marcos has
In my previous email, I included a note that said:
Note: Some elements marked as not being localizable via xml:lang, such
as screenshot and icon elements, are localizable via folder-based
content localization.
I've thought about it some more, and concluded that screenshot and
icon are actually
-ftgroup.com
From: Marcos Caceres marc...@opera.com
Reply-To: marc...@opera.com
Date: Thu, 19 Mar 2009 17:06:31 +0100
To: Andrew Welch andrew.j.we...@gmail.com
Cc: jere.kapy...@nokia.com, mark.priest...@vodafone.com,
public-webapps@w3.org
Subject: Re: [widgets] Further argument for making
Hi Marcos, All,
I would like to raise a comment in support of making the configuration
document at the root of the widget mandatory.
The localisation model currently described by [1] allows for multiple
configuration documents; zero or one at the root of the widget and zero
or one at the root
On Thu, Mar 19, 2009 at 1:15 PM, Priestley, Mark, VF-Group
mark.priest...@vodafone.com wrote:
Hi Marcos, All,
I would like to raise a comment in support of making the configuration
document at the root of the widget mandatory.
The localisation model currently described by [1] allows for
implementers :(
-Original Message-
From: marcosscace...@gmail.com
[mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres
Sent: 19 March 2009 14:25
To: Priestley, Mark, VF-Group
Cc: public-webapps@w3.org
Subject: Re: [widgets] Further argument for making config.xml mandatory
On Thu
On Thu, Mar 19, 2009 at 4:20 PM, Andrew Welch andrew.j.we...@gmail.com wrote:
Other suggestions are of course welcome!
One alternative would be to separate out the non-localisable data into a
separate document, eg manifest.xml... But this is also likely to irritate
implementers :(
No,
On Thu, Mar 19, 2009 at 4:22 PM, jere.kapy...@nokia.com wrote:
I still think that more than one config document is the most confusing
aspect of this. Having just one (mandatory) config document, with the
localized parts tagged with xml:lang attributes would be the simplest.
However, as I
On Thu, Mar 19, 2009 at 4:30 PM, Marcos Caceres marc...@opera.com wrote:
On Thu, Mar 19, 2009 at 4:22 PM, jere.kapy...@nokia.com wrote:
I still think that more than one config document is the most confusing
aspect of this. Having just one (mandatory) config document, with the
localized parts
I still think that more than one config document is the most confusing aspect
of this. Having just one (mandatory) config document, with the localized parts
tagged with xml:lang attributes would be the simplest. However, as I understand
it, the separate config files were recommended by the W3C
On Thu, Mar 19, 2009 at 4:52 PM, Andrew Welch andrew.j.we...@gmail.com wrote:
That's exactly what I was talking about when I said even thought the XML
i18n
guidelines say it's bad practice,'.
Ahh very sorry, I just saw the email after that containing the code
sample, and gmail collapses the
On Thu, Mar 19, 2009 at 5:07 PM, jere.kapy...@nokia.com wrote:
The reason why the I18N BP document frowns upon this is because if you have
the material sent for translation, it might (or most probably will) be
translated by different people in different places. So it makes coordination
a
Ok, here is my first crack at specifying this...If you prefer to read
it in the spec (so you can follow any cross references, etc), then
please check out:
http://dev.w3.org/2006/waf/widgets/#element-based-content-localization
[[
==Element-based Content Localization==
This specification defines
14 matches
Mail list logo
