-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] Simplify the Translation Process #2
Comments
We can also support dynamic params: {{ t.hash('some {{dynamic}} thing', { dynamic: propFromComponent }) }} Will transpile to: {{ t['1234567'] | translocoParams: { dynamic: propFromComponent} }} |
We can also support dynamic strings. For example: {{ t[dynamicProperty] }} And in the component: import { hash } from '@ngneat/transloco';
...
this.dynamicProperty = condition ? hash('hello world') : hash('bye'); Will transpile to: import { hash } from '@ngneat/transloco';
...
this.dynamicProperty = condition ? '261689226' : '781689346'; |
Love the idea but unfortunately, it fails in our use cases.
and besides that, you kinda bind your code to the content instead of binding it to the translation key that will probably won't change as frequently as the content of that key |
From my experience (working with a pretty large translated app) the content rarely changes, and even if you do need to change the content once in a while I'd rather use find replace and gain all the benefits of working this way. |
Another use case that I think will break:
The size of the app is not the issue, the issue is the companies and clients. Each client is different and as a 3rd party library, you cannot assume that the content won't change and sacrifice maintenance for performance. |
It seems that you misunderstood, if you want to change "Hello world" to "Good Morning Planet"
I'm not sure how is this different from changing the value of a key? it won't need to be translated to every language as well? The idea is that the new translation file created will be merged with the previous one so just this new key needs translation ( as you would need to translate it if you just change an existing key's value).
This can be achieved, allowing you to pass a custom missing key handler via an injection token is practically ready so you could do whatever you want in case there is no key.
This proposal is not all or nothing, the idea is to implement it where you can.
You don't have to use this feature if it's not meeting your needs, we are not going to force this on everyone who uses this library, it's a proposal that might fit other use cases but not yours. |
So you're saying that for every small change required by the marketing the flow is:
the current flow is:
Can you see the problem now? I don't think I have any other way to explain it.
That's good to hear and not what I've understood from your proposal. |
@ronnetzer |
@ronnetzer not sure if this is what you meant but let me try an example. There is maybe an argument to be made there that isn't good practice because the key could be become unrelated to the value/text. An example could be key = 'headerTitle' and then its intial value is 'Welcome to our site' but the release v2 it becomes 'Company Brand Name'. Then the UI changes and from release v3 that text gets placed in the footer because it's value is the companies name but the key is still saying 'headerTitle'. I hope I interpreted this conversation in the right way @ronnetzer and helped a bit. @NetanelBasal Good time so say I'm a really big fan of your work. Have read probably 90% of all you Medium blog posts and thanks for all you good tips, trick, practices and knowledge. |
@shaharkazaz In general, First we provide the translation file to the client (according to their design) and then during development, they change the content and we add new keys. for example, a simplified configuration for a dynamic form (with ngx-dynamic-forms library): [
{
"id": "name",
"type": "INPUT",
"labelTooltip": "",
"controlTooltip": "",
"label": "form.field.name.label",
"placeholder": "",
"validators": {
"required": null
}
},
{
"id": "description",
"type": "TEXTAREA",
"labelTooltip": "form.field.description.labelTooltip",
"controlTooltip": "form.field.description.controlTooltip",
"label": "form.field.description.label",
"placeholder": "form.field.description.placeholder"
}
] and the corresponding translation file: "form": {
"field": {
"name": {
"label": "Name",
"labelTooltip": "",
"controlTooltip": "",
"placeholder": "",
"errorMessage": {}
},
"displayName": {
"label": "Display name",
"labelTooltip": "",
"controlTooltip": "",
"placeholder": "",
"errorMessage": {}
}
}
} *the form's JSON configuration will be modified in the future by product/marketing/someone who's not tech-oriented. So this gives the client the ability to build/edit forms and their translations (even new keys), without any further development. In any case, there are downsides for both ways, your proposal is optional therefore it doesn't worth spending time trying to solve my rare (?) use cases, I will just stick with the current way for them :) |
@CharlBest only 90% 😜? Thanks! |
This proposal tries to simplify the translation process. The issues we face today are:
The idea is to treat each string as a ״raw string״. Word concatenation isn't valid anyway in most cases because the translators need to know the context.
We expose a hash function through the
context
object that by default, returns the given string.Now, let's run it through hashing function:
Based on these values, we can automatically generate a clean translation file in build time:
And change each usage to the corresponding hash:
Disadvantages
The text was updated successfully, but these errors were encountered: