feat: dynamic translations with data stored on database and possibly user inserted
I'm submitting a...
[ ] bug report
[x] feature request
[ ] support request
Expected behavior See this repository for a general idea of what I'm searching for. Looking at the docs, seems it's not possible to manage this atm.
Imagine, for example, a table displaying some data. Column headers display the column name, which is dynamic and have a different translation for every language and can even be edited by users to allow customization.
In this scenario (but there are others) my structure on the database will probably be
{"en": "Column name en", "it": "Nome colonna it", "es": "No hablo espanol"}
and it could be really useful to just provide the mini-json to the package, to use it in place of the static configuration.
The syntax could be something like
<!-- dynamic usage with js object -->
<span [l10nTranslate]="js object"></span>
<!-- static usage with json stringified -->
<span l10nTranslate="json"></span>
or use a different selector to remark the difference
<!-- dynamic usage with js object -->
<span [l10nTranslateDynamic]="js object"></span>
<!-- static usage with json stringified -->
<span l10nTranslateDynamic="json"></span>
``
or, to feel more like the current API, always require the input to be a stringified json/js object
```html
<!-- dynamic usage with js object -->
<span l10nTranslateDynamic> {{ stringifiedJsObject }} </span>
<!-- static usage with json stringified -->
<span l10nTranslateDynamic> serializedJson </span>
``
What do you think about this? Does some kind of workaround comes to your mind for this use case which avoids adding a new feature?
I can try to pop out some more ideas if you like the concept.
**Actual behavior**
Not present.
@IlCallo
The repo you mentioned works differently from this library, which only stores translation data for the current language.
Then I'm not sure I understand the behavior you want to achieve.
At the moment, you can get an entire translation object. I created an example: https://stackblitz.com/edit/angular-l10n-226
Do you want to achieve something like that?
If not, could you modify the example as you would (even if not working)?
I know it works differently, I put it there to define the use case (translation stored on the DB as a string/json).
The difference from the example you posted is that I'm managing dynamic translations which are not know until the very moment in which they are used (also because they can be user re-defined for every language taken into consideration).
I could probably accomplish it by activating an endpoint on my REST server which, given the fields I'm interested on, returns me JSONs with translations separated by language and then merge them at runtime in some way with this library system.
But this doubles the work: on server I must extract and separate translation, choosing a key for every string which could even be duplicated (eg when multiple columns from different tables have same field name), and on client force me to manage the fact that I must request every time first the column name translations and then the data.
I forked and updated your example, hope it's clearer what I'm trying to accomplish https://stackblitz.com/edit/angular-l10n-226-a2arzq
The logic is different.
This library uses the language as main property, and the keys as nested properties:
"en": {
"title": "Title",
"subtitle": "Subtitle",
}
instead you have:
title: {
it: 'Stringa italiana',
en: 'English string'
},
I do not think I can change the library logic the way you want, I have to think about it.
In the meantime you could use a workaround like this: https://stackblitz.com/edit/angular-l10n-226-workaround
Give it a look and let me know.
The logic is different.
Yes, I know, that's why this is a new feature :P
Give it a look and let me know.
That workaround is ok, even if the terseness of your API (which manages the locale change under the hood) at that point can be obtained only with an inpure pipe or an helper method (or my own wrapping directive).
I acknowledge that this is more like a "totally new" feature instead of an integration with existing ones. Ty for the help, if I end up implementing some general purpose code to solve this problem I'll report it here like I did for the interceptor :)
I think you can create your own translateDynamic directive or pipe without problems, but bringing them inside the library would mean creating a parallel library to handle them in all the situations (even in the translation into the classes for example).
However, keep in mind that this library doesn't use impure pipes, but only pure pipes, and the lang parameter is obtained from a decorator.
even in the translation into the classes for example
Yeah, I'd need them in classes too, so I have to do it anyway :)
However, keep in mind that this library doesn't use impure pipes, but only pure pipes, and the lang parameter is obtained from a decorator.
Yep, I saw this too, I just prefer avoiding using those decorators and encapsulate everything. I'll probably build my own directive & helper method and report them here if someone else need them
Ok, thanks!
P.S. Then if you decide to create and share a module/package for these features I can link it in this repo.
Closed due to inactivity