Errors are not translated about forms

[xificurk]

👎 Well, YOU are adding the error, it's your resposibility to translate it. Same way as is your responsibility to translate e.g. flash messages.

[fprochazka]

@xificurk control labels, select values and even validation rules are beeing passed to translator. It's just done inconsistently.

[xificurk]

@fprochazka Let's stay with errors... The problem is that you need to translate the error message before you replace placeholders in the message for their values. This must be obviously done when you're adding the error to the control. But when it's you who is "constructing" the error message, then it's your responsibility to translate it. Translating the error messages in getErrors() is simply too late.

[fprochazka]

You're absolutely right, that's why the current translation interface is not sufficient and should accept parameters argument, just like Kdyby does.

• translation interface must be fixed (ideally in backwards compatible way)
• Nette translators must adopt the new interface, ideall would the one from Kdyby, because it's backwards compatible and knows all the required functionality
• dummy translator that replaces placeholders can be added to nette
• then the parameters can be added to messages and passed to translator when the message is beeing translated

[TomasVotruba]

@xificurk My only intent is to make it consistent with labels, items values and rule messages, as @fprochazka said.

As for "replace placeholders" issue, the same would apply for placeholders in rule messages.
How do you solve them now?

The same approach can be used, couldn't be?
How would this change break your approach?

I don't want to refactor translating in Nette. For now, I wan't to only make this consistent.

[dg]

👎 for ITranslator with parameters. Expanding placeholders is not translator's job. And ITranslator has nothing to do with this issue.

I am not sure if it is good idea to have API, where setAbc($x) sets $x and getAbc() returns translated $x…

[fprochazka]

@dg there are two types of parameters in the form (errors) context. The ones' from the rule and control, that is %label, %value, %arg, ... And the second group is parameters for the message from the application perspective...

Case 1

$control->addError("front.registration.email")

where the it translates to

front:
    registration:
        email: "Your email %value is not valid"

the translator returns "Your email %value is not valid" and forms replaces the %value to what the user provided

Case 2

I've done some operations with some values in form so I wanna show the relevant value.

front:
    addressForm:
       invalidAddress: "Na zadanou adresu %address% bohužel nerozvážíme"

$control->addError($translator->translate('"front.addressForm.invalidAddress"', NULL, ['address' => $address]));
// or ? 
$control->addError("front.addressForm.address", ['address' => $address]);

I would understand if you won't accept this for ->addError(), but something like this makes a lot of sense for ->addRule()

---

I'm partially solving it by using Phrase objects, but there are parts, that strictly expect strings only and it doesn't work in all the parts of Form. Would you be willing to accept pullrequest that solves this example?

[TomasVotruba]

Not relevant anymore.