Peter Donald wrote:
> On Thu, 29 Aug 2002 17:23, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>On Wed, 28 Aug 2002 22:53, Nicola Ken Barozzi wrote:
>>>
>>>>Ok, I understand the need, but then, why under the attributes?
>>>>Why not a <description> taga ala Ant, it doesn't seem like a generic
>>>>attribut to me...
>>>
>>>The problem is when you want to do i18n of the description. Currently it
>>>is done via
>>>
>>><!-- use the following if you dont care about i18n -->
>>><attribute name="doc:description" value="Some description" />
>>>
>>><!-- use the following if you do care about i18n. -->
>>><attribute name="doc:description-key" value="my.key" />
>>>
>>><!--
>>> Note that you would have to include a resources
>>> file side-by-side the info file with the name
>>> MyClassNameInfo.*. However you could overide
>>> the location of the Info file via
>>>-->
>>><attribute name="doc:i18n-bundle" value="MyClassNameInfo2" />
>>>
>>>I think I would prefer a description element, but how would you deal with
>>>the above?
>>
>>There are various options, here are the most relevant:
>>
>>XML language identification
>>-----------------------------
>>http://www.w3.org/TR/REC-xml#sec-lang-tag
>>
>><description>
>> <p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
>> <p xml:lang="en-GB">What colour is it?</p>
>> <p xml:lang="en-US">What color is it?</p>
>> <sp who="Faust" desc='leise' xml:lang="de">
>> <l>Habe nun, ach! Philosophie,</l>
>> <l>Juristerei, und Medizin</l>
>> <l>und leider auch Theologie</l>
>> <l>durchaus studiert mit hei�em Bem�h'n.</l>
>> </sp>
>></description>
>>
>>Comment: standard, but not flexible enough.
>>
>>Cocoon i18n tags:
>>------------------
>>http://xml.apache.org/cocoon/userdocs/transformers/i18n-transformer.html
>>
>><description>
>> <para title="first" name="article" i18n:attr="title name">
>> <i18n:text>This text will be translated.</i18n:text>
>> </para>
>> <i18n:text i18n:key="key_text">Default value</i18n:text>
>> <i18n:translate>
>> <i18n:text>Some {0} was inserted {1}.</i18n:text>
>> <i18n:param>text</i18n:param>
>> <i18n:param>here</i18n:param>
>> </i18n:translate>
>></description>
>>
>>Comment:
>>important features are:
>>- Attribute translation
>>- Param substitution
>>It's more flexible and already has a Transformer to do the work, also
>>from an i18n file
>>Since Morphos can easily be made to use Cocoon Components, it can easily
>>be used as a MorpherAntTask to do the transformations.
>
>
> Both solutions all seem a bit complex. Descriptions are essentially blobs of
> text and thus don't need substitution or anything like that. All they need is
> to say blob A is in language X while blob B is in language Y.
Hmmm... I'd just keep the description in one language with descriptions
via a key in a bundle...
>>We could just use a standard name for the bundle, keep english stuff in
>>the descriptor and a key for external translations.
>
> WHich is precisely the reasoning that lead me to use attributes ;)
What about this then.
I changed the example componentinfo dtd to make it more consistent,
extensible and near to literate programming, which has struck a cord in
me lately.
We have
-[1]component-info
-[1]component-entry
-[1..n]attribute
-[1]context-entry
-[1..n]attribute
-[1..n]service-entry
-[1..n]attribute
-[1..n]dependency-entry
-[1..n]attribute
Each entry has these:
- entry - id
- version
- optional y/n
Each attribute has these:
- attribute - key
- value
- optional y/n
- included text is the description
In this way extending this is just a matter of defining new entries, and
new keys for attributes.
Entries and avalon: attributes must be in the Avalon contract, the rest
are defined by the developer, or using other internal standard.
Each xinfo file can have an xbundle file too, that maps paths to
language and translation (see below), or it can be embedded directly in
the xinfo file in a i18n entry.
<component-info>
<component id="my-component"
version="1.2.1"
optional="FALSE">
<attribute key="avalon:version"
value="1.2.1"
>This is a cool Service :-)</attribute>
<attribute key="avalon:lifestyle"
value="THREAD_SAFE"
>It must be threadsafe, or else....</attribute>
</component>
<context id = "my-context"
version = "1.1.0"
optional= "FALSE">
<attribute key="local:base"
value="java.io.File"
>The base from where all starts.</attribute>
<attribute key="local:mode"
value="java.lang.Object"
optional="TRUE"
>Keeps the mode Object, used by my system.</attribute>
</context>
<service id="my-service"
version="1.1.0"
optional="FALSE">
<attribute key="avalon:reference"
value="SimpleService"
optional="FALSE"
>This can be used to ...</attribute>
</service>
<dependency id="my-component"
version="1.2.1">
<attribute key="avalon:reference"
value="org.apache.cocoon.api.Transformer#1.1"
optional="FALSE"
>It depends on the transformer because...</attribute>
</dependency>
</component-info>
<bundle>
<item id="my-component">
<attribute="avalon:reference">
<text lang="IT">Ciao</text>
<text lang="D">Hallo</text>
</attribute>
</item>
...
</bundle>
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
