Bugzilla – Bug 6461
SC should return content to Jive based on Accept-Language header
Last modified: 2008-05-15 12:26:49 UTC
and then send a new localized menu back to Jive. Until this is fixed, the user will need to change their language on both the server and the client in order to see the change, right? Ugly, but not a showstopper for 7.0. Question: Shouldn't the language be expressed in the HTTP header? That means that the jive support on SC/SN wouldn't be stateful, right? Ben asked: Further, when SC language changes, should Jive be sent a directive to change as well? Jive supported langs are a subset of SC langs, so there may need to be some added logic to handle that. I say no. Let Jive control its language and have SC and SN respect that change.
> Until this is fixed, the user will need to change their language on both the > server and the client in order to see the change, right? Ugly, but not a > showstopper for 7.0. Couldn't Jive handle this all by itself? Set the language pref using the prefs command, request the menu again? Will have to take a look at the menu code, it might need some work to re-initialized the menu. But I don't think we need a whole new command set here. > Ben asked: Further, when SC language changes, should Jive be sent a directive > to change as > well? Jive supported langs are a subset of SC langs, so there may need to be > some added logic to handle that. > > I say no. Let Jive control its language and have SC and SN respect that > change. In the longer term we'll need a way/option to have per device language settings. If we let the Jive user change the server's language, then this can have unexpected side-effects. Imagine the hotel installation where some guest changes the device's language. Even worse if the manager can't reset the device's language from the SC side. The reason we reduced the languages stored on the server are memory consumption. I wouldn't want to revert to keeping them all in memory by default. But I think it would be easy enough to have (I hardly dare mentioning it) one more preference.
Michael: When I wrote: > I say no. Let Jive control its language and have SC and SN respect that > change. I mean that this would only affect the text displayed on Jive on a per device basis letting SC serve possibly to devices in several languages.
I also need this for SN, where it will be player-specific. An Accept-Language header would be the simplest way, but adds some extra bytes of overhead to every HTTP request.
*** Bug 7734 has been marked as a duplicate of this bug. ***
Maybe not a showstopper for 7.0, but perhaps a showstopper for 7.0.1 We can talk about this in the Thursday 9am software meeting.
See also bug 7734 and bug 6616
We should definitely not do this for 7.0.1. SC needs to be updated to support per-client languages before we can do this.
According to Jim, he's ready to slip the schedule (by some amount) to get this bug fixed. What's the effort needed to support per-client/controller languages?
I will do this tomorrow. Note this is *only* for Jive and will not affect player UI or web UI languages.
*** Bug 6616 has been marked as a duplicate of this bug. ***
Checked in a lightly-tested patch as change 19101. The thing I'm most worried about is the server returning the Jive language to other interfaces (player/web) while a Jive request is processing. Subscription requests are also not handled correctly yet. NEEDS LOTS OF TESTING. :)
I didn't see the issues Andy feared to see. But some menus won't switch language, as they register their menus at startup, but not on language change. Eg. the RandomPlay plugin or the music library.
Menus should not be using expanded strings in 'text', but string tokens to be localized when the menu is loaded. I tried fixing this by looking strings up whenever mainMenu() is called. But as text is used as the menu ID when there's no specific ID, I ended up with menus locked up, duplicate entries etc :-/. Ben - how hard would it be to use tokens instead of localized strings in the menu defintion?
Created attachment 3283 [details] Patch to reload plugin menus - mostly working - add stringToken to plugin menu definitions; stringToken is preferred over text and localized when needed - add Display::getString/Client::getString etc. (might revert this) this is mostly working. For some odd reason the "My Music" and its "Search" items don't update. But they do update if I switch server (by switching to a player connected to a different server). I see the new menu with these items in the cometd output. Maybe this is a Jive issue?
Oops... the previous patch is against 7.1...
change 19108 - the Jive specific part of the above patch (less the unneeded getString() stuff). The issue with Music Library and Search remains. localize SqueezePlay menus provided by plugins - add stringToken parameter to menu configuration; stringToken is localized and replaces text if available - use $client->string method where possible
issue with nodes not updating menu text (Music Library and Search) fixed in r2350. I think this can be moved to RESOLVED
Window title bar was not getting set with the new language for nodes (e.g, Music Library and Search). Fixed in 7.0 trunk r2351
Verified 7.0.1 - 19422
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html