Last modified: 2014-03-19 19:35:00 UTC
Message coll-load_local_book should be using {int:}} on "Ok" and "Cancel" so as to get the correctly localized versions of either string. If that is not possible, it should document (in the /qqq pseudo-language space) where these are localized so as to allow translators to use consistent wording. If these strings cannot be localized, also this needs to be documented so as to tell translators not to translate them. The message needs to use PLURAL on %NUMPAGES%. See http://www.mediawiki.org/wiki/I18n#Be_aware_of_PLURAL_use_on_all_numbers why the idea that you rarely have colloctions of one page only does not make PLURAL avoidable. It would be better to use normal MediaWiki style substitutions ($1, $2, ...) instead of special ones like %TITLE% and %NUMPAGES%. Trying to make all these requierd changes or additons, I found the source code using this message somewhat unreadable since it embeds the message into something looking like JavaScript to me without giving a clue where the parameters come from. I am not a user of the extension Collection, I am only a translator. but this one appears to me a quite central message. If the extension is meant for broad public use - why else would its messages be translated? - then I suggest that to rethink this. While it is permissible to have Javascript on secure sites, you cannot use it safely elsewhere, and you must permit users not to accept JavaScript of which they have no way to know that a true copy of what a host has sent arrived on their clients, That is, you can use JavaScript for non-essentials that are nice to have, but you cannot rely on JavaScript to function on the clients side, leave alone that there are browsers and environments that just cannot run them. Putting required functionality into JavaScript thus is just insane; and by the way, is always unnecessary.
The problem is exactly that this message is used in JavaScript code: It is shown in a JavaScript confirm() dialog when a collection has been found in the local storage[1] when the user wants to activate the book creator. At the time this message is sent to the client, the number of wiki pages in the collection isn't known yet and I'm not sure how to handle {{int:}} when a message is not rendered by MediaWiki. But I'm aware that these i18n problems are existent and should be taken care of – it's just not trivial to do so :-/ Regarding your points about JavaScript code: You can believe me that this code wouldn't be there if it was possible to do this in an easier way (and if it is, please tell me how to do it, I'll change it immediately!). The main problem is that the lifetime of cookies on WMF wikis is quite a restriction for the Collection extension: they expire on browser close. And as we don't want to (and probably won't be allowed to) use database tables to store the collections for users (which would be possible only for logged-in users anyway), cookies or some client-side technique like local storage are the only option. This is a topic that has gotten lots of thoughts and discussions and I think the users are quite happy the way it's working right now. [1] We're using http://www.jstorage.info/ to support more techniques than only actual "local storage", which isn't available for all browsers.
(In reply to comment #1) > The problem is exactly that this message is used in JavaScript code: Since this is JS and Resource Loader is now in place, does it still exist?
"Cancel" and "Ok" are still untranslated in the subwindow.
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Adding many blockers of bug 38638 to the list of "easy" bugs, to mark them as candidates for [[mw:Google Code-in]] tasks (gci2013). If you think this bug is not suitable, remove the keyword.
