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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
