Translator: keeps domain in untranslated message

[vojtech-dobes]

Fixes #19.

[fprochazka]

This is not a good solution, because the mechanism for detecting if the message was translated is also not reliable.

[vysinsky]

Maybe not good solution, but translator should not change string if it is not translated. We got into problem when we has string 'N.v.t' in selectbox - it displayed only 'v.t.' (took 'N' as domain) which is really wrong.

[fprochazka]

@vysinsky you can $control->setTranslator(NULL) on the select (or on the entire form)

Unfortunatelly, this pullrequest doesn't solve anything, it only complicates the problem.

[vojtech-dobes]

What would be your approach? What needs to be fixed first?

[vysinsky]

Ok, setting translator to NULL is possible solution. But I still think translator should NOT change strings which are not translated. It is quite wtf if you see 'user.login' in template and you have to search in 'messages' file, 'forms' file etc. - domain should stay in string as is passed to translate method.

[fprochazka]

@vysinsky I completely agree.

@vojtech-dobes

• We must fist hack the MessageCatalogues to return NULL if the message is not presented in the catalogue and if it has no fallback.
• change the usages in translator to the extended class
• then we if the thing and finally, we'll be able to tell if the catalogue actually returned something or it just juggled with the message
• profit

[TomasVotruba]

This would be great ASAP. Can I help somehow?

[fprochazka]

Closing in favour of #51