Curious why object/array returns from $t are removed?

[thedamon]

I use this frequently when defining content that is systematic.

For example when i have components that take objects, for instance, I have a FormControl component that takes an object of validationMessages keyed to validation rules. I can rely on vue-i18n to store this object exactly as I want it with no need for tricky back and forth:

// i18n
form: {
  firstNameInput:{
   label: 'first name',
   validationMessages: {
     required: 'please enter a first name',
     length: 'please ask your parents for a shorter name',
   }
 }
}

// component
<FormControl validation-messages="$t('form.firstNameInput.validationMessages)"/>

// or even
<FormControl v-bind="$t('form.firstNameInput)"/>

Or when I know something will be a list:

// i18n
cancellation: {
  reasons: [`It was too big`, `It was too small`, `It looked a bit too much like a sailboat`, `it had a strange smell`]
}

// component
<ul>
  <li v-for="reason in $t('cancellation.reasons')>{{ reason }}</li>
</ul>

This flexibility has been amazing for us, allowing us to rely on vue-i18n to store structured content that we can use programmatically (especially when defining form controls). I don't understand any benefit to ensuring objects don't come back. Is there a new function that can be used instead?

[kazupon]

Thank you for your feedback!

In this major version, $t function to return anything other than a string (object or array). Because I thought it should be a translation-only obligation.

$t function name derives from translation.
In generally, the API like $t function should be a single feature-only offering,
IMO, I think it's bat practice that putting other features into the API.

There's breaking change of return value of $t in this major version, but you're right, we should have an alternative.

Perhaps, we'll extend getMessages or provide a new function $tm (translation messages).