Forum Replies Created
-
AuthorPosts
-
jrfParticipant
Actually, I’ve figured it out by now….
The main problem is that you don’t have an update() function in your widget class.
This basically means you don’t validate *any* of the input a user gives in the widget options and whatever is received is saved to the widget $instance regardless.
Quite apart from the fact that this is unsafe and bad practice, it also means that the (English) default text phrases will be saved with the instance instead of being filtered out.
There are three ways to get around this problem:
1) Have the translation files installed with the plugin so the default strings will be available in the preferred language from the start – at least for the languages for which a translation is currently available (eh.. I get the feeling I’m repeating myself from my earlier post….)
2) The user can edit (rename) the text strings which will then be saved to the widget $instance.
However, this functionality is not very obvious in the options panel (the ‘move’ cursor is more prominent and you only see that you can actually rename the phrases in the same bit if you hover over the actual text). It doesn’t help that there is no help text or hint in the section title either.3) [BEST SOLUTION BY FAR!] Add the update() function to the widget class and properly validate every input for expected values and acceptable values.
If the input is the same as the default value, do *not ever* save it with the $instance! For the display function: use what’s in the $instance and for any options not set, use the default values.As the text string defaults are translation ready, installing a translation file later on will then no longer be a problem either.
Hope this helps.
September 24, 2012 at 4:12 pm in reply to: Internationalization: translations missing, phrases missing etc #50044jrfParticipant1. Server space is cheap, time (to figure out how to get the translations and such) is not… It’s standard practice to include all translations if you host your plugin on WordPress.org. And considering we’re currently talking about something like 500kb in server space, I would strongly suggest and advice you to include the language file by default.
2. I think you are confusing a .po file with a .pot file (which is what I was talking about). The .po files are included in your translation files, the .pot file is *not*.
The .pot file only contains the strings to be translated and serves as a translation basis/master file.
A .po file is derived from the .pot file and contains translations of the strings to one specific language.
When a new version of the plugin comes out, it will sometimes contain new strings. If there is no .pot file, each and every translator will have to manually figure out what strings are new and manually add them to the .po file for their language.
However if you use a .pot file, this becomes a whole lot easier. You generate a new .pot file for the new version of the plugin. The translators use this .pot file to *automatically* update their .po file to include the new strings (in effect the files are merged to a new .po file by the .po editor program) and the translators can then easily adjust the translation/concentrate on translating rather than figuring out what strings are new.
I hope this explanation makes it a bit clearer. You may also want to read this explanation for more info.
WordPress offers a simple way to generate a .pot file from the plugin repository admin page, I strongly suggest you try it out.
3. As explained in ad2, if you generate an up to date .pot file, this problem should solve itself really easily as translators can then just update their translation based on the .pot file.
4. Again, automatically generating a .pot file is the first step in trying to debug this as that is the only way we can be a 100% sure that all strings will be picked up corectly. If translations based on a newly generated .pot file are not being picked up, then we look elsewhere for the solution. I’ll gladly help you debug as soon as I see a .pot file.
5. Dutch translation is on it’s cyber-way to you 😉
Hope this helps.
Smile,
Juliette
September 24, 2012 at 3:51 pm in reply to: Usability suggestion enable/disable counter-intuitive #50043jrfParticipantI guess the confusion would be easily solved if you’d change the subsection heading to ‘Arrange/Enable’. What do you think ?
jrfParticipantI have the same problem with the Dutch text strings, they don’t get picked up either no matter what I do.
I don’t have a language plugin installed, and the language settings are as they should be…
September 16, 2012 at 5:56 pm in reply to: Usability suggestion enable/disable counter-intuitive #49881jrfParticipantSubscribing to the post as I forgot to do so when I created it and the subscribe/unsubscribe link at the top of the post does not seem to work for me…
jrfParticipantSubscribing to the post as I forgot to do so when I created it and the subscribe/unsubscribe link at the top of the post does not seem to work for me…
-
AuthorPosts