c++ plugins with Frameworks 5

[Aaron J. Seigo]

On Monday, March 3, 2014 12:35:40 Alex Merry wrote:
> Could we not extend scripty to do the same for the .json files?  We

most problably .. but I haven’t looked at scripty so do not know how much work 
it would be, and I try not to interfere with i18n workflows. but yes, this 
should be possible.

> would want a standard way of representing translatable and translated
> strings, and some library support somewhere to extract the correct
> version of the string for the current locale.

for a general purpose solution, yes. for the ability to represent plugin data, 
this can be encapsulated in e.g. KPluginInfo and made purpose-specific.

currently what i’m doing in sprinter plugin json is that there is a block of 
translated strings for each language with translations. e.g.:

“de”: {
	“Name”: “..”
	“Comment”: “..”
}

so when the local is set to use “de” it grabs these values. checking for 
values in the language block before returning “untranslated” strings is easy 
enough, and what kconfig does right now for INI style files.

i don’t know if we need to make this completely generic, though. it’s really 
only those two fields in the plugin info that ever get shown to the user.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140303/5013202b/attachment.sig>