Last modified: 2012-07-31 18:09:54 UTC
Background: http://www.mediawiki.org/wiki/Localisation#Messages_quoting_each_other I have the following message in an i18n file: 'ethereditor-warn-others' => 'Warning: Some other users are currently editing this page in a collaborative session using the EtherEditor extension. While you are welcome to keep editing here, their changes may conflict with yours. Please consider clicking the "{{int:ethereditor-collaborate-button}}" button in the top right of the page screen to join them, and avoid merge conflicts.' This is a great thing and all, since I don't want people to need to update this message if the ethereditor-collaborate-button message gets changed. OK, good stuff. However, the JavaScript message object has two huge problems with this: 1. The JS message object doesn't even glance at the {{int:....}} part, just leaves it. 2. Even if it did look at it, I never included 'ethereditor-collaborate-button' in the required messages for this module, so there would be exactly no way for the library to sanely handle the int-hack method. So, possible solutions: 1. Compile the int-hack bits of the message on the server before it gets sent to the client. This isn't ideal, since the client couldn't modify the message if necessary (for example, I use a message in the same extension to generate a regular expression). 2. Auto-include the int-hacked messages (in this case, ethereditor-collaborate-button) in the resource loader's loaded messages, and then consider {{int:}} parts of a message while parsing. This would take some doing, but it's possible. Also, a potential problem (and this is perhaps a consideration for the entire l10n system, not just client-side) is that {{int}} is a valid template on some wikis. I'm not sure if that's important, maybe if the parser looks for {{int:<something>}}, there won't be overlap with {{int|something}}. Thanks!
Interesting, the 2nd solution sounds like the better solution in this case keeping in mind the way messages are loaded and parsed. Also note that the client side parser does support parser functions in general (e.g. it has logic for detecting them, this is used for {{GRAMMAR:}} and {{PLURAL:}}). Changing to be an 'enhancement' instead of a bug, as the status quo is that that is not supported on the client, so messages intended for client-side use should not contain these in the first case as they were never supported in the past either.
