Use of Arrays

[rbayley]

Hi,
First, congrats on such a great job.

I notice vuex-i18n flattens arrays and so:

[
"before_or_equal" => "The :attribute must be a date before or equal to :date.",
"between" => [
"numeric" => "The :attribute must be between :min and :max.",
"file" => "The :attribute must be between :min and :max kilobytes.",
"string" => "The :attribute must be between :min and :max characters.",
"array" => "The :attribute must have between :min and :max items.",
],
"boolean" => "The :attribute field must be true or false."
]

Becomes
[
validation.before_or_equal:"The :attribute must be a date before or equal to :date."
validation.between.array:"The :attribute must have between :min and :max items."
validation.between.file:"The :attribute must be between :min and :max kilobytes."
validation.between.numeric:"The :attribute must be between :min and :max."
validation.between.string:"The :attribute must be between :min and :max characters."
validation.boolean:"The :attribute field must be true or false."
]

Why is this so ?
It would be interesting it didnt, that way we could loop through specific path.
If there is some option to do so, please let me know.

Thanks !

rb

[rbayley]

Sorry, duplicate
#60

using lodash _.get wouldnt it help ?

[tikiatua]

Hi @rbayley,

Thank you for your feedback. Honestly, I am not completely sure anymore why we opted to use a flattened translation index.

It is probably at least partially due to the way that the plugin evolved. We did try to provide users with a simple api to specify translation keys, while trying to keep the "lookup" method from becoming to costly.

This is especially an issue, since the translation lookups are run every time the respective component is evaluated for re-rendering – unlike a computed property, that is only evaluated when corresponding elements in the vuex store are changed.

However, I cannot recall if we actually did take some measurements on the computing time of a flattened index vs object lookups.

In my opinion, the best solution would be, if there was a way to transform the lookup function into a computed property, so that it is only run if the locale or the keys in the store are changed. However, I have not yet had the time to look into this.

Could you provide me with a snippet of how you would like to use an unflattened translation tree, so that I can think about how this could be implemented?

[rbayley]

Hi @tikiatua

Thanks for your reply.

The reason I need to keep the original non-flattened Object is that in some cases I need to loop through the content.

For example.
{
"title":"Some title",
"sections":{
"section1":"my sections name",
"section2":"other section name"
}
}

Therefore if I want to create a list (simple li tag) I can loop through "sections" and get correct data.
When flattening, I don't see how I can do so. Maybe by filtering the entire locale.

Anyways, I have been looking into your code and thought about having two objects within the locale.

1. translations (current) with all flattened values. Used in the $t() function
2. unflatten (new) with original object value, exposing it through a getter.

the ADD_LOCALE() mutation can update both the translations flattened object and the new unflattened.

Not sure if or how this will hurt performance.

Just a thought.