Support parameters in keys about localisation HOT 12 CLOSED

I want this too by won't be able to work on it too soon.

A PR would be appreciated.

from localisation.

Now I think I understand your problem. We can extract the helper function in a file and import it in the mixin file, or wherever we need it.

from localisation.

FYI: had other priorities popping up but I should be able to provide a PR for this soonish (with a bit of luck this week; otherwise more towards 2nd week of december)

from localisation.

It turns out implementing this was simpler than expected.

PR coming up (in Core, as changes were in the __ mixin & localisation store only; which resides there)

Notables:

• Key collection code was moved to the store to improve compatibility (__ can be called from within the store too, previously this didn't trigger the collector) & allow collecting of parameterized keys (cleanly)

• It does also support uppercasing according to the parameter (full uppercase & first letter uppercased)

• We should probably consider moving the missing key logic (tracking array & request) outside of the main store to reduce code smell (the store is being imported into the localisation module as that sadly enough was the cleanest solution without moving addMissingKey out of the localisation store; it works; I haven't discovered any issues doing it this way; but it's most likely wasting some resources)

Thoughts on/possibilities for addMissingKey:

• Leave as is (should be ok as it's a route only used on local environments, basically as a development aid; long-term effects unknown)
• Move to a separate store (is it worth creating a store for an axios.patch & storing an array?
• Make the patch call directly from the getter; store the pending keys in a window or document-level array?

from localisation.

Sorry for the delay but I'm abroad and I have limited time near the computer.

Key collection code was moved to the store to improve compatibility (__ can be called from within the store too, previously this didn't trigger the collector) & allow collecting of parameterized keys (cleanly)

From the store point of view __ is a getter. From the app point of view __ is a global helper for translation. Before having the key collection logic the global helper's role was just avoiding having to use mapGetters in every component.

Moving the key collection logic to the store, as a general idea does not increase any "compatibility", you already have access to this.__ from every component and don't need to map the getter.

The current implementation for the key collector was not the cleanest architectural choice but its utility combined with the fact that is usable only in dev mode made it worth it.

I'll comment further on the PR.

from localisation.

Sorry for the delay but I'm abroad and I have limited time near the computer.

No problem

The current implementation for the key collector was not the cleanest architectural choice but its utility combined with the fact that is usable only in dev mode made it worth it.

I understand, hence why it remained intact (but moved to the store as you don't have the middleware available from within the store)

and don't need to map the getter.

No indeed, but you had to manually add the keys instead of them being collected with anything using this.__; with the move this is no longer the case.

from localisation.

No indeed, but you had to manually add the keys instead of them being collected with anything using this.__; with the move this is no longer the case.

What do you mean?

from localisation.

That code is located in the store (as it affects the store & is used globally in different ways)
The mixin doesn't apply here; and thus it's logic had to be moved to the store itself for it to work as expected (more cases are following where we require a similar approach)

edit: note that "incorrect credentials" here only applies to a temporary (non-Enso) authentication required in certain cases; it's unrelated to the actual session's login user

from localisation.

Sounds like a reasonable alternative.
Sorry for the late reply btw, I've been coping with illness.
I'll make the requested changes soon (will be for next week though as I have to catch up & holidays coming up starting wednesday ;) )

from localisation.

Where are we on this?

from localisation.

Only got back from holiday yesterday, will be done after completing our backlog (hopefully tomorrow now)

from localisation.

Updated, see laravel-enso/core#87

from localisation.