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:
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.