First of all, your development efforts with the plugin are much appreciated. You’re doing a great job!

I understand well that you would prefer not to just use the gettext translation files, because that would make it harder to customize the strings for the average user.

I am not entirely sure what would be the best approach in this case, but your suggestion of making it an option whether to use the default translation strings or the customized strings, is certainly one way.

My immediate thought was to filter everything through a “__” or “_e” command, because that would
1) Automatically make lookups against the active gettext translation
2) Allow other plugins (such as qTranslate, which I am using) to process language tags. For example if I customized one of the strings to be [:en]English[:it]Italiano, qTranslate would cause the resulting output to be “English” if English was the active language or “Italiano” if Italian was the active language.

Perhaps I’ll create a thread on your forum about this, where we can discuss it more thoroughly.

Have a nice day!

As for the multilanguage strings, I’d love to see what you have in mind to solve this issue. I’d like not to use multiple .po files, since most users don’t know how to edit them. But maybe I could add an option to specify if the plugin should use the strings in the database or those in the .po files. This way those who need a multilanguage environment, would be able to do so. Let’s discuss…

Camu