Strings in shortcuts/overrides.xml need to be localized

[jingai]

Well, hrmm.. tried to do this, and it will show the localized strings on the Home window, but in the widget selector in script-skinshortcuts.xml, it doesn't translate them..

I notice some other skinners don't localize these either.. that seems odd to me, but oh well.

[jingai]

Added in the non-functional translations, but stubbed them out for now. Will ask on forums about how to do this properly.

[ghost]

I always consider this to be a largely Kodi issue (regarding the widget labels specifically). My expectation is that Kodi would - as any time you set a label in gui xml - automatically translate the labels in the select dialog. But it doesn't.

What does work is setting the label to just the id of the string e.g. "31497" - in that case the skin shortcuts script will localise it before its displayed. However, it will only accept a single string id - you can't do "20386 31497" for example, and it can't handle any strings from another add-on (Kodi doesn't let python scripts access the strings from other addons via the api).

[jingai]

The latter part is the problem -- some of the labels are not single strings. I could make individual strings in my skin for them, but it's my understanding that we should try to shy away from that because they won't translate across skins if you do.

So... rock and a hard place, it seems.

[ghost]

Don't worry about them translating across skins for pretty much anything but menu item names. Most everything else - widgets included - is skin specific and doesn't transfer across.

[jingai]

Ok. So the only thing supported is single integer values? Things like $ADDON[script.skinshortcuts xxxxx] won't work? Also, does it support both Kodi internal strings as well as skin strings?

Obviously I can just check.. but looking for verification of what's 'officially' supported.

[ghost]

The code that does the translating will translate any Kodi, skin or skinshortcuts string ID. If the ID is between 31000 and 31999 it assumes its a skin string, 32000 and 32999 a script string, otherwise a Kodi string. It's also not entirely just an integer value - there are a few different formats it accepts

::LOCAL::xxxxx ::SCRIPT::xxxxx $LOCALIZE[xxxxx] $ADDON[script.skinshortcuts xxxxx]

But in all cases it can only handle a single instance. (Though I'll bear it in mind to extend it in a future update when using $LOCALIZE - but the function in question is used everywhere so I'll need to think through what it might break first!)

(And to clarify the menu names switching between skins - the same code thats doing this translation has an additional function whereby it saves the last translation and which skin it came from, so if using another skin the label won't be localised anymore, but it will still be whatever the last translation was - so don't worry too much about menu items with skin-strings in them :wink:)

[jingai]

Thank you so much for the clarification.

[jingai]

@Ignoble61, so the $ADDON[script.foo xxxxx] syntax only works for script.skinshortcuts? If so, I've got a whole lot of strings to store :(

[ghost]

Only in the widget select dialog (and certain other cases where the script uses the select dialog via the python API) as Kodi won't translate the strings in that case, so the script has to do it.

For things like available shortcuts, backgrounds (dependant on exactly how they're used - the way the select dialog is called varies), the new widget 312 method and so on, you can use that for any add-on, as we're accessing the select dialog in a totally unofficial way, but one whereby Kodi actually translates the strings.

[jingai]

Hmm. I'm currently using button 309 for selecting a widget. Are you saying I should be using button 312?

I tried replacing button 309 with 312, but it does nothing. Is this not in the Helix version of script.skinshortcuts?

[ghost]

312 is the gui button for the new method of managing widgets in Skin Shortcuts 0.6.0, but yes, it's only available on Isengard and higher (and fundamentally works quite differently from the 'classic' 309 method which, though deprecated in 0.6.0, will continue to work.) And sorry, not saying you should be using 312, but simply that the new widget method uses the select dialog in the way that Kodi will translate strings.

[jingai]

Ok. I think for now then, instead of polluting my language files with a ton of strings, I'll just release for Helix as-is and use the new 312 button for Isengard.

When you say 'fundamentally different,' do you mean under-the-hood, or that it's not as simple as changing my button ID from 309 to 312? I've already added the type properties to the widgets in overrides.xml, so I think besides localizing the remainder of the strings, that should be it, yes?

Wouldn't mind if you could briefly have a look at the overrides.xml I just pushed up in https://github.com/stoli/Metropolis/commit/1534f35f17901a370a3ba1359553aa087b8dfe49 just to verify it's 0.6.0-ready (besides the rest of the localization).

[ghost]

It's not as simple as changing the button ID from 309 to 312. Take a look at the documentation for full details, but the new widget method allows the user to select from a lot more widgets (library nodes, add-on nodes, playlists, sources), as such return quite different properties, and obviously requires the skin to support them.

It's optional, though - even though 309 is deprecated, the code for it won't be removed any time soon (only at a point where there are no skins on the repo using it, or likely to be any anytime soon).

The overrides are 0.6.0 ready, as in they'll work with that version. I can't comment on skin-integration, other than to say they don't have all the properties that the new widgets return, but it will be up to you as the skinner which of those properties you rely on ;)

(My own advice, for what its worth, if you're wanting to do a Helix push don't worry about the 312 method of widgets until you're actually on Isengard and have the time to evaluate what skin changes they'll need and whether you'll actually want to support them)

[jingai]

Ok. Thanks again for your very prompt and thorough replies!