Could we add in an action get message to the api or add some functionality to meta=allmessages ?
Really need to be able to: A) send in parameterized replace values per msg key B) get the html rendered / parsed result (rather than the wikitext)
Security wise the parameterized replace values should be treated as wikitext and go through the wiki-text-parser before rendered back out to the browser.
Otherwise we have to do quite a few calls to generate a msg text that has a parametrized wiki-text-value.
--michael
2009/5/5 Michael Dale mdale@wikimedia.org:
Could we add in an action get message to the api or add some functionality to meta=allmessages ?
Really need to be able to: A) send in parameterized replace values per msg key B) get the html rendered / parsed result (rather than the wikitext)
Security wise the parameterized replace values should be treated as wikitext and go through the wiki-text-parser before rendered back out to the browser.
Otherwise we have to do quite a few calls to generate a msg text that has a parametrized wiki-text-value.
Use action=parse&text={{int:messagename|param1|param2}} ?
Roan Kattouw (Catrope)
On Tue, May 05, 2009 at 09:10:16AM -0700, Michael Dale wrote:
Could we add in an action get message to the api or add some functionality to meta=allmessages ?
Really need to be able to: A) send in parameterized replace values per msg key B) get the html rendered / parsed result (rather than the wikitext)
Security wise the parameterized replace values should be treated as wikitext and go through the wiki-text-parser before rendered back out to the browser.
I'm not sure how feasable that would actually be, as the messages are not all handled the same way. In fact, as far as I know there isn't even any generic way to tell how any particular message is handled besides "read the source". It all depends on how exactly the message is used in the code that actually makes use of it.
Among other possibilities, the message could be treated as plain text, as raw HTML, as fully-parsed wikitext (action=parse), or as preprocessed-only wikitext (similar to if not the same as action=expandtemplates); see the various wfMsg* functions. Substitution of the parameters could be done before or after the message itself is processed, and the individual parameters could themselves have been processed in any manner before being passed to wfMsgWhatever.
And then the output could potentially be run through the parser again before actually making it to the browser.
Otherwise we have to do quite a few calls to generate a msg text that has a parametrized wiki-text-value.
For most cases, you should only need one or two: one to fetch the message, and possibly one to process it (either before or after substituting the parameters). A third call to action=parse might be needed if it's one of those "preprocess, substitute, then parse" messages mentioned above and you're going all the way to HTML output.
Of course, depending on the message you might need earlier calls to process the individual parameters before substitution, if you can't figure out the final parameter content client-side.
Do you have an example of a message that requires quite a few calls?
2009/5/5 Brad Jorsch b-jorsch@northwestern.edu:
On Tue, May 05, 2009 at 09:10:16AM -0700, Michael Dale wrote:
Could we add in an action get message to the api or add some functionality to meta=allmessages ?
Really need to be able to: A) send in parameterized replace values per msg key B) get the html rendered / parsed result (rather than the wikitext)
Security wise the parameterized replace values should be treated as wikitext and go through the wiki-text-parser before rendered back out to the browser.
I'm not sure how feasable that would actually be, as the messages are not all handled the same way. In fact, as far as I know there isn't even any generic way to tell how any particular message is handled besides "read the source". It all depends on how exactly the message is used in the code that actually makes use of it.
Among other possibilities, the message could be treated as plain text, as raw HTML, as fully-parsed wikitext (action=parse), or as preprocessed-only wikitext (similar to if not the same as action=expandtemplates); see the various wfMsg* functions. Substitution of the parameters could be done before or after the message itself is processed, and the individual parameters could themselves have been processed in any manner before being passed to wfMsgWhatever.
Good point. Because parameter substitution is trivial (e.g. with PHP's strtr() function) and all other functions (preprocess, parse) are available already, this doesn't need any additional functionality.
Roan Kattouw (Catrope)
On Tue, May 5, 2009 at 1:47 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
2009/5/5 Brad Jorsch b-jorsch@northwestern.edu:
On Tue, May 05, 2009 at 09:10:16AM -0700, Michael Dale wrote:
Could we add in an action get message to the api or add some functionality to meta=allmessages ?
Really need to be able to: A) send in parameterized replace values per msg key B) get the html rendered / parsed result (rather than the wikitext)
Security wise the parameterized replace values should be treated as wikitext and go through the wiki-text-parser before rendered back out to the browser.
I'm not sure how feasable that would actually be, as the messages are not all handled the same way. In fact, as far as I know there isn't even any generic way to tell how any particular message is handled besides "read the source". It all depends on how exactly the message is used in the code that actually makes use of it.
Among other possibilities, the message could be treated as plain text, as raw HTML, as fully-parsed wikitext (action=parse), or as preprocessed-only wikitext (similar to if not the same as action=expandtemplates); see the various wfMsg* functions. Substitution of the parameters could be done before or after the message itself is processed, and the individual parameters could themselves have been processed in any manner before being passed to wfMsgWhatever.
Good point. Because parameter substitution is trivial (e.g. with PHP's strtr() function) and all other functions (preprocess, parse) are available already, this doesn't need any additional functionality.
Roan Kattouw (Catrope)
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
On that note and similar, I had been thinking about just this same issue recently.
Rather than a new API module (which would be redundant, as Roan points out), what if we added some new Ajax functions? Then JS has access to messages, but we're not relying on custom Http requests to the API to get them.
-Chad
El 5/5/09 10:57 PM, Chad escribió:
On that note and similar, I had been thinking about just this same issue recently.
Rather than a new API module (which would be redundant, as Roan points out), what if we added some new Ajax functions? Then JS has access to messages, but we're not relying on custom Http requests to the API to get them.
What do you mean by "new Ajax functions"? If you mean the godawful sajax interface, then it should die and be buried and forgotten.
-- brion
On Tue, May 5, 2009 at 2:58 PM, Brion Vibber brion@wikimedia.org wrote:
El 5/5/09 10:57 PM, Chad escribió:
On that note and similar, I had been thinking about just this same issue recently.
Rather than a new API module (which would be redundant, as Roan points out), what if we added some new Ajax functions? Then JS has access to messages, but we're not relying on custom Http requests to the API to get them.
What do you mean by "new Ajax functions"? If you mean the godawful sajax interface, then it should die and be buried and forgotten.
-- brion
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Whatever the interface, I was more interested in the end result: ability to get localized messages via JS, and without having to request them by hand from the API.
-Chad
2009/5/6 Chad innocentkiller@gmail.com:
On Tue, May 5, 2009 at 2:58 PM, Brion Vibber brion@wikimedia.org wrote:
El 5/5/09 10:57 PM, Chad escribió:
On that note and similar, I had been thinking about just this same issue recently.
Rather than a new API module (which would be redundant, as Roan points out), what if we added some new Ajax functions? Then JS has access to messages, but we're not relying on custom Http requests to the API to get them.
What do you mean by "new Ajax functions"? If you mean the godawful sajax interface, then it should die and be buried and forgotten.
-- brion
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Whatever the interface, I was more interested in the end result: ability to get localized messages via JS, and without having to request them by hand from the API.
I have some Ajax functions to emulate getMsg and a couple of variants. But it's from before API.php and needed two calls for some things:
http://en.wiktionary.org/wiki/User:Hippietrail/wfMsgCentre.js
Andrew Dunbar (hippietrail)
-Chad
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
El 5/5/09 12:46 PM, Chad escribió:
Whatever the interface, I was more interested in the end result: ability to get localized messages via JS, and without having to request them by hand from the API.
I believe that's what functions are for. :) You're not supposed to manually do any sort of ajax call, API or otherwise, as it's about a billion extra lines of code.
-- brion
Brad Jorsch wrote:
... depending on the message....
yea your email highlights how things really have to be handled on a per msg basis. The parser function {{int:msgname|param}} that Roan pointed out will work for my existing use cases. Eventually we will need to paralyze a few of our language functions into JS. But we will have to handle this on a per msg basis.
--michael
mediawiki-api@lists.wikimedia.org