Skip to content
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

[Enhancement] Test (and modify) all our components to make them support or handle i18n and l10n. #324

Closed
16 of 20 tasks
emoralesb05 opened this issue Feb 5, 2017 · 11 comments
Closed
16 of 20 tasks

Comments

@emoralesb05
Copy link
Contributor

emoralesb05 commented Feb 5, 2017

Feature Request

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:

  • Common (Pipes)
    • Digits
    • Bytes
    • TimeAgo
    • TimeDifference
  • Chips
  • Data Table
  • Dialogs
  • Expansion Panel
  • File
  • Json Formatter
  • Layout
  • Menu
  • Notifications
  • Paging
  • Search
  • Steps
  • Dynamic Forms
  • Highlight
  • Markdown
@ghost
Copy link

ghost commented Feb 6, 2017

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.

@crain
Copy link

crain commented Feb 7, 2017

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 ?

@emoralesb05
Copy link
Contributor Author

emoralesb05 commented Feb 7, 2017

@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.

@quanterion
Copy link
Contributor

@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 angular/angular#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.

@ocombe
Copy link

ocombe commented Mar 7, 2017

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 :-)

@emoralesb05
Copy link
Contributor Author

emoralesb05 commented Mar 8, 2017

@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)

@ocombe
Copy link

ocombe commented Mar 8, 2017

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 emoralesb05 modified the milestones: Beta 4 (maybe RC?), Beta 3 Mar 31, 2017
@emoralesb05 emoralesb05 removed this from the Beta 4 milestone May 14, 2017
@parker-mike
Copy link

parker-mike commented Jun 14, 2017

@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?

@emoralesb05
Copy link
Contributor Author

@parker-mike you need to use the columns input to set your own labels.

@parker-mike
Copy link

@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?

@emoralesb05
Copy link
Contributor Author

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();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants