Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [riena-dev] Location for messages.properties? 
But dont you have to reference the keys when you translate the bundle. Then you want to build bundles or fragments for other languages that are based on the keys in the message.properties file. I think thats why Elias was thinking of it as API, because if we change key, then thats like an API change, because translations get broken. But if equinox.security does it different that probably means there are different flavors what people think how it should be done.

I think we should not put it in an internal bundle, but just into a seperate package named <bundlename>.nls

christian

Am 05.03.2010 um 14:06 schrieb Schepp, Frank:

> In eclipse bundle org.eclipse.equinox.security it is done this way. Also I think normally class Messages is only used bundle internal.
> 
> Frank
> 
> -----Ursprüngliche Nachricht-----
> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christian Campo
> Gesendet: Freitag, 5. März 2010 13:23
> An: Riena Developers list
> Betreff: Re: [riena-dev] Location for messages.properties?
> 
> Why an internal package ? Messages are not internal but considered API (see Elias below) since other want to translate them......
> 
> christian
> 
> Am 05.03.2010 um 13:16 schrieb Schepp, Frank:
> 
>> One more question: Should an internal package be used? I.e. instead of package org.eclipse.riena.core.nls package org.eclipse.riena.core.internal.nls is used?
>> 
>> Frank
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Christian Campo
>> Gesendet: Freitag, 5. März 2010 09:50
>> An: Riena Developers list
>> Betreff: Re: [riena-dev] Location for messages.properties?
>> 
>> 
>> Am 05.03.2010 um 08:31 schrieb Stefan Liebig:
>> 
>>> I think the per-bundle-solution would be sufficient for us because we do 
>>> not have a lot of translatable messages.
>>> Although (very unlikely) the per-package-solution would make it easier 
>>> to move packages between bundles because of some refactoring.
>>> 
>>> Additionally, I would also like to define a least a hint for formatting 
>>> the message keys, e.g.:
>>> <class.getSimpleName()>[_<someOptionalQualifier>]_<camelCaseOfTheEnglishMessage>
>> 
>> +1 good plan
>>> 
>>> BTW, I know of projects (p2) that also make exception messages 
>>> translatable. I think this goes too far. What do you think?
>> 
>> +1 for not translating exception message texts.
>>> 
>>> Tschüß,
>>> Stefan
>> 
>> who else has an opinion....????
>> 
>> christian
>>> 
>>> On 04.03.2010 23:01, Christian Campo wrote:
>>>> Hi Elias,
>>>> 
>>>> I talked about the exact same topic today with Frank Schepp. We thought of rule like this:
>>>> - have only one file (messages.properties) per bundle / project
>>>> - put it in a package named<bundle-id>.nls
>>>> 
>>>> So org.eclipse.riena.core would have a package org.eclipse.riena.core.nls with a messages.properties with all text entries for that bundle.
>>>> 
>>>> Does that sound like a good idea to everyone ?
>>>> 
>>>> christian
>>>> 
>>>> Am 04.03.2010 um 19:03 schrieb Elias Volanakis:
>>>> 
>>>> 
>>>>> Here's something I would like to discuss:
>>>>> 
>>>>> What is the best location for messages.properties / Messages.java
>>>>> files. The options could be:
>>>>> 
>>>>> - having a dedicated messages.properties per package
>>>>> - or having a dedicated messages.properties per bundle (ideally with
>>>>> some naming scheme)
>>>>> 
>>>>> The reason for mentioning this is that moving the .properties file to
>>>>> another package breaks existing translation fragments. From the POV of
>>>>> somebody who has an existing translation the location of that file (as
>>>>> well as the key names that are already in  it) should be considered
>>>>> API.
>>>>> 
>>>>> Looking forward to your input,
>>>>> Elias.
>>>>> 
>>>>> -- 
>>>>> Elias Volanakis | Technical Lead | http://eclipsesource.com
>>>>> elias@xxxxxxxxxxxxxxxxx | +1 503 929 5537 | @evolanakis
>>>>> _______________________________________________
>>>>> riena-dev mailing list
>>>>> riena-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/riena-dev
>>>>> 
>>>> 
>>>> -------------------------------------------------------------
>>>> compeople AG
>>>> Untermainanlage 8
>>>> 60329 Frankfurt/Main
>>>> fon: 069 / 27 22 18 0
>>>> fax: 069 / 27 22 18 22
>>>> web: www.compeople.de
>>>> Vorstand: Jürgen Wiesmaier
>>>> Aufsichtsratsvorsitzender: Christian Glanz
>>>> Sitz der Gesellschaft: Frankfurt/Main
>>>> Handelsregister Frankfurt HRB 56759
>>>> Ust-Ident.-Nr: DE207665352
>>>> -------------------------------------------------------------
>>>> _______________________________________________
>>>> riena-dev mailing list
>>>> riena-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/riena-dev
>>>> 
>>> 
>>> _______________________________________________
>>> riena-dev mailing list
>>> riena-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/riena-dev
>> 
>> _______________________________________________
>> riena-dev mailing list
>> riena-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/riena-dev
>> _______________________________________________
>> riena-dev mailing list
>> riena-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/riena-dev
> 
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev
> _______________________________________________
> riena-dev mailing list
> riena-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/riena-dev

Back to the top