Krinkle (2011-03-31 01:43):
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.
True, but let's suppose we have a developer that only knows: * Polish (native) * German (de-5) * English (en-2)
Naturally the main person who maintains translations is the developer. And so natural gradation of languages would be pl>de>en. But if that would complicate Tin code too much then I don't think it's that important.
Krinkle (2011-03-31 01:43):
[...] 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".
In wiki you wrote:
* suppresserrors (bool): Allows a tool to suppress errors, which will prevent TsIntuition from showing fatal errors (will also suppress notices) * suppressnotices (bool): Allows a tool to suppress errors, which will prevent TsIntuition from showing notices
I think it should either be the other way around (notices suppressing errors) or I wouldn't call them "fatal". Fatal for me is when an application halts in execution.
If by suppresserrors you mean showing values in braces then I would make errors and notices separate. So it would possible to have notices disables to not clutter the error.log but still be able to quickly see what is still to be translated (is in braces).
Krinkle (2011-03-31 01:43):
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 ? [...]
Wasn't this suppose to be a system where you have some groups of messages common to many tools of many authors? I thought whole domain idea was about this - one domain for my tool(s) and other domains for other tools and some common domains loaded optionally. For example: * "general" could contain things like "OK", "Cancel", "Close", "Language"... * "namespaces" could contain all namespaces translation * "editcounters" could contain phrases common to counters (e.g. "number of edits", "deleted edits")
Regards, Nux.