https://bugzilla.wikimedia.org/show_bug.cgi?id=19190
Trevor Parscal <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX --- Comment #1 from Trevor Parscal <[email protected]> 2009-06-15 17:29:18 UTC --- Hopefully there can be a solution to this that makes sense - as I see all your points. Hover the current implementation is as such for the following reasons. * The messages with wikitext in them are input examples, and need to be unparsed wikitext because they are illustrating the type of syntax one would use in a wiki page. * The messages with HTML in them are output examples which would initially be considered a great candidate for using the parsmag option with wfMsg, however the code the parser outputs is not always the same as the code we want in the examples - as the examples are merely visual representations of what the output will look like, and not intended to be fully functional. Additionally, these bits of code may include images which are bundled with the toolbar itself as to not depend on the existence of an uploaded image in the wiki. This is especially important when distributing the toolbar to many different wikis - remember this is not only for English Wikipedia, and it will also be used by non-Wikimedia projects. * The messages are being inserted (without parsing) into a javascript loadGM() function. The client side gM() function can perform $1 replacements, but cannot perform any parsing. Eventually the inserting of messages into loadGM() will not be done with PHP, but rather the messages will be replaced inline on a javascript file by a script server (just before minification and packing), and the limitations of this future implementation are dictating the current one. This is an important transitional component of this software, and unless the script server is made to perform actual parsing, the messages used on the client should remain as they are right now. It may be possible to make the text strings (which need actual translation, compared to the HTML parts which don't) their own independent messages, allowing translators to perform their work without stepping around HTML. This could potentially be done using the client-side $1 replacement functionality as well. However, this will also introduce even more individual messages which begin to loose context by the time the translation is taking place possibly making them more difficult. My understanding, especially when discussing this type of software (JavaScript UI), is that there is an intention to move towards more simple internationalization messages (meaning, those which do not require full parsing) Suggestions on alternative implementations are welcome. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
