Last modified: 2014-11-01 00:52:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T68199, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 66199 - The output of wfMessage( 'i-dont-exist' )->text() should not have its entities html encoded
The output of wfMessage( 'i-dont-exist' )->text() should not have its entitie...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 62047 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-06-05 16:20 UTC by Erik Bernhardson
Modified: 2014-11-01 00:52 UTC (History)
11 users (show)

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


Attachments

Description Erik Bernhardson 2014-06-05 16:20:24 UTC
wfMessage( 'i<dont>exist' ) has a two possible outputs depending on the format utilized to output the content, either:

plain: <i&lt;dont&gt;exist>
text/escaped/parse: &lt;i&lt;dont&gt;exist&gt;

Note that i'm not encouraging special characters in i18n keys, merely showing what the current implementation does.

The method documentation for Message::text() states that it is unescaped message text. Documentation for Message::plain() states that it is unescaped untransformed text. Based on the documentation my inference is that text() and plain() should have the same output, with {{FOO}} messages transformed only in the text method.

One option for escaping is to escape as close to the output as possible. In an API response consumed by client-side javascript the strings within the JSON should be plain text. This plain text is then escaped for output in the templating layer of the client side javascript. Using this setup mistyping an i18n key looks like you have not only bad i18n key but also a double-encoding issue.  Upon further investigation the double-encoding only happens with the non-existent key.

I'm proposing the output should be:

plain/text: <i<dont>exist>
escaped/parse: &lt;i&lt;dont&gt;exist&gt;
Comment 1 Gerrit Notification Bot 2014-06-05 16:22:23 UTC
Change 137458 had a related patch set uploaded by EBernhardson:
Correct output of wfMessage( 'non-existent-msg' )->text()

https://gerrit.wikimedia.org/r/137458
Comment 2 Krinkle 2014-06-07 08:42:14 UTC
*** Bug 62047 has been marked as a duplicate of this bug. ***
Comment 3 Gerrit Notification Bot 2014-09-23 21:15:05 UTC
Change 137458 merged by jenkins-bot:
Message: Correct output of wfMessage( 'non-existent-msg' )->text()

https://gerrit.wikimedia.org/r/137458

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


Navigation
Links