Maciej Jaros wrote:
Looks promising, maybe just one question...
(...)
Cheers, Nux.
I'd love to answer any questions you have, however from your e-mail I conclude that you are a developer yourself. Please refer to the following files in SVN and the documentation.
If your questions / concerns / suggestions still stand, I'm happy to answer hear then of course.
Back-end system: http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/ToolserverI18N/
(other than for localhost testing please do not check this repo out to your ts-account, instead php-include the central checkout in the central i18n directory. Otherwise your messages will not be updated.)
Documentation of PHP Class and utility functions: https://wiki.toolserver.org/view/Toolserver_Intuition
Maciej wrote:
Do you plan to make the first fallback language set-able by the tool developer? Some tools are for certain wikis (in certain language) and would be best to have the fallback to the language of the wiki the tool was designed for.
No. Although I will consider this if there are more use-cases, for the scenario you described I believe it would not be desirable if developers set their own fallback order.
If your tool is primarily written for a Hungarian Wikimedia project, make sure your tool messages are available in Hungarian and anyone who has their language preference set to hungarian will see the tool in that language.
The language choice will be remembered by TsIntuition across all tools. So if you visit a tool once and set your language, if you visit a totally different tool the next week it will default to the language you choose the previous week for that other tool (if available), and otherwise it's fallback, and otherwise the system default (English).
Maciej wrote:
I'm not sure if it's a good idea, but did you thought about bulk updates of the list of messages? The main problem I'd like to address is making a new tool with a lot of new or very specific texts. How would I get them translated quickly just for testing? How would I quickly lunch an application with main users in one language but with bigger perspectives in few months?
I think these are separate questions, so I will answer them as such.
As said before, one of the main powers of this tool will be that there is no decentralization of localization. There is 1 place where the i18n system is located which is only updated for one of three reasons: * synchronization update from TranslateWiki * software update my me or someone else on the team (right now just me) * a text-domain ('message group for a tool') is added or removed from the cycle.
BTW. What would be returned if a message is not found? I think a notice should be thrown and the message should be returned as is. Meaning _('Something to be written') would return 'Something to be written'. And the notice probably should be optional (not thrown when testing).
In default mode inexistent messages will return [keyname].
So $I18N->msg('blabla') (or _('blabla') ) will return the "[blabla]" string. The reason for the brackets is because this should never happen in practice and indicates an important error.
It should never happen in production for two reasons: * The source language (eg. 'en') should have each message defined. if this is not the case, the developer did something wrong. * Other languages may but do not have to have each message defined. Because of the fallback system a message is always found.
I like your idea of the notice. Added it in r85052 [1]. notices are suppressed by default. To show them set 'suppressnotices' to false in the options [2]. See also this demo [3].
Errors (in contrary to notices) are shown by default. If those are set to false the [brackets] will not be shown and the message will be returned exactly as the key with the first letter uppercase [4]. so instead of "[blabla]" it reads "Blabla".
Also I think there has to be some mechanism for overriding some variables. This is done on Wikipedia by changing a message on local MediaWiki page and it doesn't affect other Wikis. Similarly certain tool author could change (should be able to) some message to better suit it's tool while leaving the name unchanged. One should be encouraged to change the translation on TRLwiki or add a new translation, but I think we shouldn't force him to do so.
I presume you mean 'messages' by 'variables'. Please note that the perspective is very different from that of a wiki. Toolserver users (users that have a toolserver account and can develop tools) are the developers. They define the messages for their tools. Why would you want to override your own messages ?
Although you didn't name it, there are scenarios where you want to quickly modify a message to try something (ie. development and debugging purposes). In that case one can use the setMsg()-method to override a message [5].
I think you may have misunderstood the context or goal of this system a little bit. There is no scenario I can imagine in which a tool author would want to "change a message to better suit it's tool while leaving the name unchanged". He (the tool author, is the person who created those messages in the first place. He can just change the original message if there's something wrong.
Translation goes through TWN (TranslateWiki.net), what other way would you propose ?
Nux wrote:
It was supposed to be one question, but... :-)
Variable replacement ($1, $2, etc.)
$welcome = $I18N->msg('welcomeback', array( 'variables' =>
array( $username, $lastvisit ) ) from [[Toolserver:Mytool-welcomeback]] which contains "Welcome back $1 (last visit: $2)".
I think named variables work much better then those driven by certain order.
For example:
$welcome = $I18N->msg('Welcome back', array('username'=>$username, 'lastvisit'=>$lastvisit)) [[Toolserver:Mytool-Welcome back]] contains: "Welcome back {{username}} (last visit: {{lastvisit}})".
Could be shorter but still usable:
$welcome = $I18N->msg('Welcome back', array('u'=>$username, 'v'=> $lastvisit)) [[Toolserver:Mytool-Welcome back]] contains: "Welcome back %u (last visit: %v)".
Using numbered variables has been the convention for MediaWiki for a long time and translators have gotten used to them. Other then that, they are language independent, easier to parse and require less typing.
It's not a big deal to add named parameters though, however the syntax will be like $username and $v and not {{username}} as those cause unneeded confusion with templates and/or template parameters.
Nux wrote
Sorry, but one more thing - what about offline (localhost) testing? Will there be a downloadable message file?
There already is [0]. If you're outside toolserver scope (ie. localhost) you can use SVN checkout [6] to install it locally. All you have to do is require_once('ToolStart.php'); and you're ready to roll.
Nux wrote
Cheers, Nux.
You're welcome. Thanks for your interest in i18n!
-- Krinkle
[0] http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/ToolserverI18N/ [1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85052 [2] https://wiki.toolserver.org/view/Toolserver_Intuition#construct [3] http://toolserver.org/~krinkle/TsIntuition/sandbox2.php [4] http://toolserver.org/~krinkle/TsIntuition/sandbox3.php [5] https://wiki.toolserver.org/view/Toolserver_Intuition#setMsg [6] http://www.mediawiki.org/wiki/Svn#Check_out