Last modified: 2014-03-19 19:35:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 25442 - Message MediaWiki:coll-load_local_book message: "Cancel" and "Ok" are untranslated in the subwindow
Message MediaWiki:coll-load_local_book message: "Cancel" and "Ok" are untrans...
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
Collection (Other open bugs)
unspecified
All All
: Normal normal with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://translatewiki.net/w/i.php?titl...
: easy, i18n
Depends on: 20962
Blocks: messages
  Show dependency treegraph
 
Reported: 2010-10-07 11:28 UTC by Purodha Blissenbach
Modified: 2014-03-19 19:35 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Purodha Blissenbach 2010-10-07 11:28:17 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.
Comment 1 Johannes Beigel 2010-11-04 09:41:48 UTC
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.
Comment 2 Mark A. Hershberger 2011-04-01 20:07:43 UTC
(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?
Comment 3 Purodha Blissenbach 2011-04-04 02:09:51 UTC
"Cancel" and "Ok" are still untranslated in the subwindow.
Comment 4 Bugmeister Bot 2011-08-19 19:12:28 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 5 Nemo 2013-11-19 12:36:06 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links