(2017-03-08, 18:57)ronie Wrote: [ -> ]2017-03-05 kodi language file changes
not a python related change, but it can potentially affect your addon..
as of PR#11039 the kodi language file no longer uses '%s' / '%i' string formatting.
in case your addon is using any of the affected strings from the kodi language file, please be aware this will no longer work:
Code:
xbmc.getLocalizedString(20464) % foo
xbmc.getLocalizedString(299) % count
pull request: https://github.com/xbmc/xbmc/pull/11039
Ronie,
Is there an alternative? Removing the ability to have formatted strings in the language kind of goes against the developer rules about having to store text in a string file instead of hard coding it in a py file.
(2017-03-09, 03:50)Protocol-X Wrote: [ -> ][quote='ronie' pid='2544100' dateline='1488992258']
2017-03-05 kodi language file changes
not a python related change, but it can potentially affect your addon..
Ronie,
Is there an alternative? Removing the ability to have formatted strings in the language kind of goes against the developer rules about having to store text in a string file instead of hard coding it in a py file.
Ha, it got you too.
Read the post carefully, it concerns only re-using strings from the main language file that now will have different formatting.
(2017-03-08, 18:57)ronie Wrote: [ -> ]2017-03-05 kodi language file changes
not a python related change, but it can potentially affect your addon..
as of PR#11039 the kodi language file no longer uses '%s' / '%i' string formatting.
in case your addon is using any of the affected strings from the kodi language file, please be aware this will no longer work:
Code:
xbmc.getLocalizedString(20464) % foo
xbmc.getLocalizedString(299) % count
pull request: https://github.com/xbmc/xbmc/pull/11039
should we convert to using .format()
or just construct the phrases by connecting them as words?
e.g.: xbmc.getLocalizedString(298)+' '+somethingvariable+' '+xbmc.getLocalizedString(299)
(2017-06-05, 21:16)gedisony Wrote: [ -> ] (2017-03-08, 18:57)ronie Wrote: [ -> ]2017-03-05 kodi language file changes
not a python related change, but it can potentially affect your addon..
as of PR#11039 the kodi language file no longer uses '%s' / '%i' string formatting.
in case your addon is using any of the affected strings from the kodi language file, please be aware this will no longer work:
Code:
xbmc.getLocalizedString(20464) % foo
xbmc.getLocalizedString(299) % count
pull request: https://github.com/xbmc/xbmc/pull/11039
should we convert to using .format()
or just construct the phrases by connecting them as words?
e.g.: xbmc.getLocalizedString(298)+' '+somethingvariable+' '+xbmc.getLocalizedString(299)
If you're still wondering: you shouldn't be using xbmc.getLocalizedString at all as these strings can be removed or changed to something else at any time. (I don't know this function is even still there). Instead, add your own to your addon and use xbcmaddon.Addon().getLocalizedString. Those won't be affected by changes like these.
(2018-01-28, 13:23)takoi Wrote: [ -> ]you shouldn't be using xbmc.getLocalizedString
well that's news to me :-)
both skins and addon extensively use the kodi language file.
there are even a lot of strings in there that aren't used by kodi core, but only by skin.estuary.
it saves translators a lot of work if an addon re-uses strings from the kodi language file,
instead of adding the same string to the addon language file.
best practice has always been, use strings from the kodi language file as much as possible
and only add missing strings to your addon language file.
Well for skins it can be fine if you want it to be exactly the same as estuary. But for random add-ons it's a terrible practice because as I said core string can change to something completely different, even between minor versions. And this change will be silent for add-ons.
In addition, if you are not 100% sure yours and and core string are for the exact same context it will often be wrong in other languages. And this is very hard to know without checking the source code.
The extra translator work is a non-issue imo as transifex have a share 'memory'. It's one click to reuse a string
I agree with @
takoi, re-using UI strings is a terrible idea.