[Yanel-dev] Language version API

[Michael Wechner]

Josias Thöny wrote:

> Michael Wechner wrote:
>
>> Josias Thöny wrote:
>>
>>> Hi,
>>>
>>> Michi proposed to store the information about language versions as 
>>> follows in the resource configuration:
>>>
>>> <yanel:property name="language" value="de"/>
>>>
>>> <yanel:custom-config 
>>> xmlns:xr="http://www.wyona.org/yanel/resource/xml-resource/1.0">
>>>   <xr:alternative-languages>
>>>     <xr:alternative-language lang="en" href="/about_en.html"/>
>>>     <xr:alternative-language lang="es" href="/es/acerca.html"/>
>>>   </xr:alternative-languages>
>>> </yanel:custom-config>
>>
>>
>>
>> well, that would be one way of implementing it, but I guess it's not 
>> so good, because with more than 2  languages a lot
>> of information would be duplicated
>
>
> That's right. And considering that there might be other config/meta 
> data common to all language versions, I'd prefer to have an additional 
> common file for this purpose.
> But I have no idea how to do this in the framework...


well, the resource config could link to this meta file via a UUID or the 
meta files are being referenced by a dedicated config on its own in 
order to avoid that every URL needs a dedicated resource config 
especially if we want to use the chain of responsibility.

>
>>
>>>
>>>
>>> Now the question is how to make this accessible in java. Maybe we 
>>> could introduce a "Translatable" interface for resources which 
>>> support multiple language versions:
>>>
>>> interface Translatable {
>>
>>
>>
>> what about calling the interface something like "I18nable"?
>
>
> Personally I prefer Translatable to I18nable, because I associate i18n 
> with translation of the application, not of the content.
> But it doesn't matter that much to me.


so, let's keep it translatable

>
>>
>>>     String getLanguage();
>>
>>
>>
>> don't we have this method already within one of the other interfaces 
>> and hence will lead to problems when mixing?
>
>
> I could not find this method in any of the existing interfaces.
>
>>
>>>     String[] getLanguages();
>>
>>
>>
>> I guess this will return all languages, I mean including the one from 
>> which this method is being called, right?
>
>
> That's what I meant.


ok, so I guess we just have to document this within the Javadoc

>
>> Otherwise it probably should be called getAlternativeLanguages()
>>
>>>
>>>     Resource getTranslation(String language);
>>
>>
>>
>> I guess this method could be used to figure out the path
>>
>> getTraslation(String language).getPath() right?
>
>
> yes.
>
>>
>>>     void addTranslation(Resource resource, String language);
>>
>>
>>
>> wouldn't we have to add a path here?
>
>
> The path is part of the resource parameter.


right

> Maybe it would be sufficient to pass just the path instead of the 
> resource, I don't know.


I think the resource as you suggest it is good as long as resource 
always need to be created with a path associated.

Cheers

Michi

>
> josias
>
>>
>>>     void removeTranslation(String language);
>>>     boolean hasTranslation(String language);
>>> }
>>>
>>> WDYT?
>>
>>
>>
>> sounds good to me, whereas I would consider another implementation ;-)
>>
>> Thanks
>>
>> Michi
>>
>>>
>>> josias
>>>
>>> _______________________________________________
>>> Yanel-development mailing list
>>> Yanel-development at wyona.com
>>> http://wyona.com/cgi-bin/mailman/listinfo/yanel-development
>>>
>>
>>
>
>
> _______________________________________________
> Yanel-development mailing list
> Yanel-development at wyona.com
> http://wyona.com/cgi-bin/mailman/listinfo/yanel-development
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
michael.wechner at wyona.com                        michi at apache.org
+41 44 272 91 61