I've been looking into how to use i18n for translations in an Angular app. My struggle is with string interpolation, it seems this has not been implemented into Angular yet.
Goal: Use i18n to translate string interpolation of collection in an Angular app to have a Spanish version.
What I've done: I've been doing a lot of research, and the workarounds I've seen mentioned are:
Polyfill: ( https://github.com/ngx-translate/i18n-polyfill ) (and referenced here: angular-i18n Angular 6 Internationalisation : How to deal with variables )
Hidden div: (Angular internationalization (i18n) and *ngFor )
Verbose method: using n-container and ngswitch. Seems the least clean way: https://github.com/angular/angular/issues/11405#issuecomment-415731284
For a collection like an array, or a database table, how are these workarounds creating separate i18n tags for each element? Will it end up showing just one tag for all elements of the collection?
For example: If you have an array for "Gender", with values of "Male" and "Female", what will happen?
<mat-option *ngFor="let gender of genders" [value]="gender.value">
{{ gender.viewVal }}
</mat-option>
In the polyfill they mention:
test {{myVar}} !", {myVar: "^_^"})
Does that mean "^_^" is the translation? It's done directly in the typescript, not in an xlf file?
If you use a hidden div, how does using the typescript file affect the xlf? The verbose method seems easiest to understand but not good for scalable, what if you have a dropdown with 10+ items, then that really bulks up the code.
What is the best way to go about this goal? I'm not sure I properly understand how the polyfill works and there is not much documentation on these ways of translation.
Related
I'm working on a website where I want to add the settings of my Slick Slider trough the data-attribute. This is possible with the 'data-slick' attribute. The format for this looks like this: data-slick='{"slidesToShow": 4, "slidesToScroll": 4}'.
In my WordPress CMS I'm using the plugin 'Data Attributes' to add data attributes to a Gutenberg Block. Trough this plugin all double and single quotes are converted to and therefor changes on the frontend to data-slick="{"slidesToShow": 4, "slidesToScroll": 4}"
This is not working. The Slick Slider doesn't use these settings.
Is there another way to add a JSON object into a data-attribute so it will work with the Slick Slider?
Thanks already for your help!
Kind Regards,
Nick
I think storing a JSON value in HTML is a bad idea. There are too many conditions which you have to take into consideration - backend returning page, WEB server encoding (it can add a custom encoding header), and browser compatibility. For this task, I'd prefer 2 ways: bitwise mask or simple function-for example, define a few data attributes -data-s1, data-s2, data-sn. In the JS code, add an array [ data-s1, data-s2, data-sn]. And finally, add a loop with an in-condition (if data.contains(element of array) - read and then parse the data inside of the attribute). I never worked with wordpress but for JS it is a easy task. If you need example write comment below. I can update my answer
What is the minimum example, if any, using the Polymer PWA (https://polymer.github.io/pwa-starter-kit/), to show correctly a vaadin-grid?
I tried many different combinations, but never a working one, with, often, this warning:
property-accessors.js:275 Polymer::Attributes: couldn't decode Array as JSON
Am I doing anything totally wrong?
Thanks
Andrea
Starting from the v5.2.0-beta1 we recommend using following Grid features:
column helper elements (vaadin-grid-filter-column, vaadin-grid-sort-column)
column convenience properties (path, header and text-align)
renderers for more complex cases where you previously used templates
See the example here: https://glitch.com/edit/#!/lying-blanket?path=app.js:29:42
https://lying-blanket.glitch.me/
Note: I'm using fetch API here for simplicity only, you can use XHR if necessary.
To set string #Input() properties of the component, we can use two type of syntax:
<my-component caption="Hello there" type="primary" someThing="text value"></my-component>
OR:
<my-component [caption]="'Hello there'" [type]="'primary'" [someThing]="'text value'"></my-component>
I'm fully aware of the differences between those two types of bindings. The question is: If I have bunch of string #Input() properties that I want to set statically, can I use simple attribute binding syntax (first example) than more "meaty" property binding syntax (second example)?
What is the recommendation, and why? I.e. what are the trade-offs and is it preferable to use property-binding always, even for setting static string inputs?
Here are the few drawbacks I can think of:
Attribute bindings are actually applied as HTML attributes, and e.g.
user can see/alter them via browser's dev tools easily. Property
bindings are not part of the markup.
Attribute bindings might collide
with actual HTML attribute names (unless you prefix them with data-
which defeats the whole purpose of simplicity). Actual example that
already bit me is title attribute.
There is no intellisense in markup for attribute bindings with Angular Language Service.
But the major advantage is the simplicity. In the example above, you would agree that the first form is more elegant. In my projects it seems that big number of properties are constant (one-time-set) string properties, and the syntax makes actual difference in readability.
So... Is it a bad practice to use attribute-binding syntax for custom (non-HTML) string properties? (Given the fact that I'm aware/ok with above listed few limitations)
These are a couple of things I like to add:
Attributes are just plain static fields.
There is a fine line when attributes become properties.
Simplicity is not the goal here, modularity and reuse-ability is.
Property binding give you more control in your component and you can use a component in any like any data-driven or static scenario.
One component build right with property binding can be used in 20 different projects.
But if you got no such requirement then you can use attributes. They are fine.
I will not say which one is better, both have their use cases but overall property bindings are lot more powerful and flexible.
And last thing I like to mention for all readers:
In front-end development any one can modify the code. We use
validations just to provide a smooth user experience. Other than that
any one can get the code or alter HTML if they want to, that's why we
use server side validations. Angular pipe line is complex but
hack-able. A user can wrap a JSON object and send it to server
bypassing all our validations. So for all readers who are new front-end
devs, we don't bother too much about security, we try our best to give
a good user experience.
I am working since last few months with PLAY 1.2.5 using Java and HTML for views. I am aware of using JAVA code in PLAY templates using %{ if ------else}% (kind of as we use scriplets in J2EE. But now I came across use of tags like #{if}---{/if}. I searched around and found that this also is a way of using if-else. But my query is that in a similar piece of code I saw the following:
#{if some variable value in Controller == 'true'} ------- #{/if} #{else}------ #{/else} .
Now I don't understand how this Controller variable is accessed in controller within these tags. I have looked around and found that no such variable was rendered by render() or renderArgs() from the controller.
Is there any other way of using those variables/methods on templates which are declared in controllers or model for that matter?
Both mustache and handlebars are awesome. I like them both for their individual simplicity and excellence. Mustache because it's a one template works in lots of places and handlebars because it provides just a few more features.
The challenge I have is that they seem to have been implemented to output HTML or some other document structure where the tags are in pairs and there are no separators.
To further clarify, if you have an array of items that would be output in a list then this works well:
<ul>
{{#each items}}
<li>{{name}}</li>
{{/each}}
</ul>
This works great. But if you want to output something JSON-like:
[
{{#each items}}
{ name:{{name}} }
{{/each}}
]
This does not work because JSON requires that there be commas separating items in a list. And you cannot put a comma after the innermost '}' because that would cause an error too.
There are several posts/recommendations where people have requested that an optional separator attribute be added to the #each or adding a #join. One committer said that it should be implemented as a plug-in because the core needs to be simple.
The politics aside. Being able to format a javascript object as a JSON string seems well suited for templates.
**One final idea. There may actually be a better Javascript Idiom for reformating a JavaScript object. I suppose that would also be interesting to consider.
PS: the one reason I like the template is because it becomes self documenting.
UPDATE:
#Kevin over at the handlebarsjs team was able to create a "Helper" function that implemented the feature I was missing. It's not like to make it into the core any time soon but that code worked:
[
{{#join items sep=','}}
{ name:{{name}} }
{{/join}}
]