We need to make sure all our components either handle i18n and l10n, or atleast are flexible enough so the text could be replaced.
Covalent Modules:
One thing (I work a lot outside the US) that I really appreciate is either opting in to localized text or having a message letting me know that i am seeing translated content with a prominent link to the default language.
Would this only support i18n the Angular2 native way or would it be possible to override labels via Input parameters to use frameworks like https://github.com/ngx-translate/core ?
@forrest-lyman that is more of an issue on implementation and UX on the product side, but its a nice feature we can implement in our internal products.
@crain For the most part we want every piece of text to be provided on consumption through inputs/templates to allow that flexibility. Maybe only a few might have hardcoded english strings that can be overridden by those inputs.
We are probably gonna start using ngx-translate ourselves, so we want to work well with it.
@emoralesb05 Why are you going to use ngx-translate? I can see one showstopper to use native Angular i18n - that is translating text inside source files. But @ocombe, the creator of ngx-translate is now a core contributor in Angular and going to solve this issue soon https://github.com/angular/angular/issues/11405
PS: I do think native angular i18n is more efficient since it produce no runtime penalty and all hard work is done is compilation stage that can be significant for big enterprise apps.
I am working on this right now, there is currently a blocker because I need to wait for the implementation of TypeScript transformers into tsc_wrapper for Angular (the team is working on this), but if everything goes well, this should land around 4.2 (maybe 4.3). This is a rough estimate since the blocker is not up to me :-)
@quanterion Yes, i've been following the progress of ngx-translate and @ocombe transition as contractor for the angular core team and i am super excited about that feature.
you answered in that statement the reason why angular's native i18n doesnt work for me. I dont want to have n builds for n languages to be honest, but when that feature is available we will migrate to it. This however is for our internal products, covalent should stay agnostic of this.
@ocombe Awesome man! Looking forward to all that, and using ngx-translate in the meantime for our internal products so hopefully its not gonna be a big leap jumping from ngx-translate to the core implementation? (fingers crossed haha)
I'll try to help with the migration by updating ngx-translate to support i18n tags, but there will be a bit of "replace in folders" to do :)
I agree that the n builds for n languages is a bit cumbersome, I'd love to have an option to support multiple languages in one build (even if the payload is higher), but it's definitively not for now, I'll have to convince the googlers and that will be hard.
@emoralesb05 The Data Table is marked as able to handle i18n and l10n. I didn't find a proper way to localize labels without using atomic components. There is a tdDataTableTemplate directive that can be used to customize the data cells for a column, but as far as I can see we don't have anything like that for the headers(so we can translate the labels), so how the labels should be localized?
@parker-mike you need to use the columns input to set your own labels.
@emoralesb05 That's how I'm working now, but this way I can't use the translation pipe. Sorry, I didn't mention that I'm using the ngx-translate as suggested in the docs. Can you elaborate on this a little bit please?
So i do this in one of the internal products, but you can set they keys as labels and then do something like this
this.columns.forEach(async (col: ITdDataTableColumn) => {
if (col.label) {
col.label = await this._translate.get(col.label).toPromise();
}
});
this.dataTable.refresh();