From takeshi at nii.ac.jp  Mon Nov 21 23:20:31 2016
From: takeshi at nii.ac.jp (Takeshi NISHIMURA)
Date: Tue, 22 Nov 2016 13:20:31 +0900
Subject: Language-independent properties
Message-ID: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>

Hi all,

I'm a member for Japanese translation.

One suggestion.
It seems useful to comment out some properties, which are language-independent (e.g. 'idp.logo' and event/exception to error key mappings).
Otherwise, deployers must modify all the property files they deployed to take effect.

Sincerely,
Takeshi

From lukas.haemmerle at switch.ch  Tue Nov 22 02:59:18 2016
From: lukas.haemmerle at switch.ch (=?UTF-8?Q?Lukas_H=c3=a4mmerle?=)
Date: Tue, 22 Nov 2016 08:59:18 +0100
Subject: Language-independent properties
In-Reply-To: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
Message-ID: <76576209-8b12-c0b4-af83-622fb5eb5500@switch.ch>

Hi Takeshi

On 22.11.16 05:20, Takeshi NISHIMURA wrote:
> I'm a member for Japanese translation.
> 
> One suggestion.
> It seems useful to comment out some properties, which are
> language-independent (e.g. 'idp.logo' and event/exception to error key
> mappings).
> Otherwise, deployers must modify all the property files they deployed to
> take effect.

Good point. Just yesterday we have been discussing internally at SWITCH
how to best deploy the translations.

Some strings like the idp.logo will have to be changed by all IdP
administrators. If one uncomments this value for example in the Japanese
translation, where would you define idp.logo then?
If one configures this in system/messages/messages.properties changes
will be overwritten by the next update.

At SWITCH we are considering to propose in our IdP deployment guide to
leave the system/messages/messages.properties untouched, install the
translations in messages/messages_[de|it|fr].properties (like Shibboleth
recommends it) untouched as well but make the IdP load additional files
messages/custom_messages_[en|de|it|fr].properties, which contain the
local changes (e.g. to set logo or IdP name) that not only survive
updates of the IdP but also updates of the translations.

This will require a one-time change in the Shibboleth configuration though.

Best Regards
Lukas


-- 
SWITCH
Lukas H?mmerle, Central Solutions
G?ANT Project Task Leader of
eduGAIN Service Development - Research and Service Providers
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 05, direct +41 44 268 15 64
lukas.haemmerle at switch.ch, http://www.switch.ch

From takeshi at nii.ac.jp  Tue Nov 22 03:26:13 2016
From: takeshi at nii.ac.jp (Takeshi NISHIMURA)
Date: Tue, 22 Nov 2016 17:26:13 +0900
Subject: Language-independent properties
In-Reply-To: <76576209-8b12-c0b4-af83-622fb5eb5500@switch.ch>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
 <76576209-8b12-c0b4-af83-622fb5eb5500@switch.ch>
Message-ID: <fe23f8de-786a-28f2-9423-6ebc97aa3de6@nii.ac.jp>

> where would you define idp.logo then?
> If one configures this in system/messages/messages.properties changes
> will be overwritten by the next update.

There is a file messages/messages.properties (not in system/) for language-independent properties and default values for customized messages.

This file is originally empty with the following comments.
> # You can define message properties here to override messages defined in
> # system/messages/ or to add your own messages.

On 2016/11/22 16:59, Lukas H?mmerle wrote:
> Hi Takeshi
>
> On 22.11.16 05:20, Takeshi NISHIMURA wrote:
>> I'm a member for Japanese translation.
>>
>> One suggestion.
>> It seems useful to comment out some properties, which are
>> language-independent (e.g. 'idp.logo' and event/exception to error key
>> mappings).
>> Otherwise, deployers must modify all the property files they deployed to
>> take effect.
>
> Good point. Just yesterday we have been discussing internally at SWITCH
> how to best deploy the translations.
>
> Some strings like the idp.logo will have to be changed by all IdP
> administrators. If one uncomments this value for example in the Japanese
> translation, where would you define idp.logo then?
> If one configures this in system/messages/messages.properties changes
> will be overwritten by the next update.
>
> At SWITCH we are considering to propose in our IdP deployment guide to
> leave the system/messages/messages.properties untouched, install the
> translations in messages/messages_[de|it|fr].properties (like Shibboleth
> recommends it) untouched as well but make the IdP load additional files
> messages/custom_messages_[en|de|it|fr].properties, which contain the
> local changes (e.g. to set logo or IdP name) that not only survive
> updates of the IdP but also updates of the translations.
>
> This will require a one-time change in the Shibboleth configuration though.
>
> Best Regards
> Lukas

From cantor.2 at osu.edu  Tue Nov 22 08:56:27 2016
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 22 Nov 2016 13:56:27 +0000
Subject: Language-independent properties
In-Reply-To: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
Message-ID: <9846A6064BD102419D06814DD0D78DE112A99A71@CIO-TNC-D2MBX02.osuad.osu.edu>

> One suggestion.
> It seems useful to comment out some properties, which are language-
> independent (e.g. 'idp.logo' and event/exception to error key mappings).
> Otherwise, deployers must modify all the property files they deployed to
> take effect.

I'm probably going to need an example to understand what's not working as intended. My assumption is you'd do it in messages/messages.properties and I thought that was the global override if you don't want the default in the system version. I probably just don't know the sequence it's actually using so if you walk me through an example it will help. Maybe there's just a problem in how it's all declared to the system.

The general question of how to handle the "official" translations is certainly open. I was thinking it made sense to put them in user land but that may be wrong and certainly isn't necessary.

We just have to set some ground rules. The installer won't remove files in system/ it doesn't know about, but we don't want to accidentally step on anything either.

I really wouldn't think you'd need to start adding more message sources though, I assumed "user" and "system" would be enough.

-- Scott


From takeshi at nii.ac.jp  Tue Nov 22 09:33:34 2016
From: takeshi at nii.ac.jp (Takeshi NISHIMURA)
Date: Tue, 22 Nov 2016 23:33:34 +0900
Subject: Language-independent properties
In-Reply-To: <9846A6064BD102419D06814DD0D78DE112A99A71@CIO-TNC-D2MBX02.osuad.osu.edu>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
 <9846A6064BD102419D06814DD0D78DE112A99A71@CIO-TNC-D2MBX02.osuad.osu.edu>
Message-ID: <B6B3EB4A-5427-42B9-8604-913075A06176@nii.ac.jp>

Hi Scott,

Currently, all our messages_*.properties have idp.logo defined.
> idp.logo=/images/dummylogo.png

So, assumed that messages_*.properties are stored in messages/ (not in system/), I must change all the 'idp.logo' lines (or comment out them) in addition to put it into messages/messages.properties.
> idp.logo=/images/organization.png

If they were already commented out in messages_*.properties, it might be easy to change idp.logo property.

Takeshi

> 2016/11/22 22:56?Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> One suggestion.
>> It seems useful to comment out some properties, which are language-
>> independent (e.g. 'idp.logo' and event/exception to error key mappings).
>> Otherwise, deployers must modify all the property files they deployed to
>> take effect.
> 
> I'm probably going to need an example to understand what's not working as intended. My assumption is you'd do it in messages/messages.properties and I thought that was the global override if you don't want the default in the system version. I probably just don't know the sequence it's actually using so if you walk me through an example it will help. Maybe there's just a problem in how it's all declared to the system.
> 
> The general question of how to handle the "official" translations is certainly open. I was thinking it made sense to put them in user land but that may be wrong and certainly isn't necessary.
> 
> We just have to set some ground rules. The installer won't remove files in system/ it doesn't know about, but we don't want to accidentally step on anything either.
> 
> I really wouldn't think you'd need to start adding more message sources though, I assumed "user" and "system" would be enough.


From cantor.2 at osu.edu  Tue Nov 22 10:06:12 2016
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 22 Nov 2016 15:06:12 +0000
Subject: Language-independent properties
In-Reply-To: <B6B3EB4A-5427-42B9-8604-913075A06176@nii.ac.jp>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
 <9846A6064BD102419D06814DD0D78DE112A99A71@CIO-TNC-D2MBX02.osuad.osu.edu>
 <B6B3EB4A-5427-42B9-8604-913075A06176@nii.ac.jp>
Message-ID: <9846A6064BD102419D06814DD0D78DE112A99B18@CIO-TNC-D2MBX02.osuad.osu.edu>

> So, assumed that messages_*.properties are stored in messages/ (not in
> system/), I must change all the 'idp.logo' lines (or comment out them) in
> addition to put it into messages/messages.properties.
> > idp.logo=/images/organization.png

But if they were in system/ that's not the case, right? So I guess that means scratch that idea, they really should go in system/, and of course that makes more sense anyway.

> If they were already commented out in messages_*.properties, it might be
> easy to change idp.logo property.

At the moment, though, the official distribution now puts that in system/ so it shouldn't matter what *we* do, I think this is more about what we need to advise people to do with third party files.

-- Scott


From takeshi at nii.ac.jp  Tue Nov 22 10:52:09 2016
From: takeshi at nii.ac.jp (Takeshi NISHIMURA)
Date: Wed, 23 Nov 2016 00:52:09 +0900
Subject: Language-independent properties
In-Reply-To: <9846A6064BD102419D06814DD0D78DE112A99B18@CIO-TNC-D2MBX02.osuad.osu.edu>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
 <9846A6064BD102419D06814DD0D78DE112A99A71@CIO-TNC-D2MBX02.osuad.osu.edu>
 <B6B3EB4A-5427-42B9-8604-913075A06176@nii.ac.jp>
 <9846A6064BD102419D06814DD0D78DE112A99B18@CIO-TNC-D2MBX02.osuad.osu.edu>
Message-ID: <AF106982-DA35-40CD-90B3-F02FE56929A8@nii.ac.jp>

Yes, exactly. But I think it is still meaningful that messages_ja.properties only contains differences from messages.properties.

Takeshi

> 2016/11/23 0:06?Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> So, assumed that messages_*.properties are stored in messages/ (not in
>> system/), I must change all the 'idp.logo' lines (or comment out them) in
>> addition to put it into messages/messages.properties.
>>> idp.logo=/images/organization.png
> 
> But if they were in system/ that's not the case, right? So I guess that means scratch that idea, they really should go in system/, and of course that makes more sense anyway.
> 
>> If they were already commented out in messages_*.properties, it might be
>> easy to change idp.logo property.
> 
> At the moment, though, the official distribution now puts that in system/ so it shouldn't matter what *we* do, I think this is more about what we need to advise people to do with third party files.
> 
> -- Scott
> 
> _______________________________________________
> i18n mailing list
> i18n at shibboleth.net
> http://shibboleth.net/mailman/listinfo/i18n


From cantor.2 at osu.edu  Tue Nov 22 11:59:49 2016
From: cantor.2 at osu.edu (Cantor, Scott)
Date: Tue, 22 Nov 2016 16:59:49 +0000
Subject: Language-independent properties
In-Reply-To: <AF106982-DA35-40CD-90B3-F02FE56929A8@nii.ac.jp>
References: <30036d4d-24ff-de69-0255-f4d0d7971f54@nii.ac.jp>
 <9846A6064BD102419D06814DD0D78DE112A99A71@CIO-TNC-D2MBX02.osuad.osu.edu>
 <B6B3EB4A-5427-42B9-8604-913075A06176@nii.ac.jp>
 <9846A6064BD102419D06814DD0D78DE112A99B18@CIO-TNC-D2MBX02.osuad.osu.edu>
 <AF106982-DA35-40CD-90B3-F02FE56929A8@nii.ac.jp>
Message-ID: <9846A6064BD102419D06814DD0D78DE112A99DC4@CIO-TNC-D2MBX02.osuad.osu.edu>

> Yes, exactly. But I think it is still meaningful that messages_ja.properties only
> contains differences from messages.properties.

Ok, that's fair. I just needed to see what the scenario was. I would suggest somebody file a RFE for that. We do have embedded fallbacks for most of our messages, so I imagine we could do this in a lot of places.

-- Scott


