-
-
Notifications
You must be signed in to change notification settings - Fork 571
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
Why ngx-translate exists if we already have built-in Angular2+ i18n ? #495
Comments
Because you don't always want to reload your entire application when someone switches the language. Angular i18n forces you to build the application per language. |
As mentioned in the official documentation we have the choice between JIT/AOT compilation |
Because they aim to different purposes, for example try to change your application language with a click with the native library of angular |
Hello, this is a good question, and as I am working on i18n in the Angular core team I am probably the best to answer this. The idea behind this lib has always been to provide support for i18n until Angular catches up, after that this lib will probably be deprecated. For now, there are still a few differences between Angular i18n and this library:
|
Perfect Answser TY ! |
So why dont you at angular call the guys from ngx and integrate ngx instead of reinventing the wheel? |
@josersleal that's exactly what they did, the angular team hired me to improve i18n for everyone |
Hi
Sorry I missed that part :)
Keep up the good work..
Thank you:
José R. S. Leal
…On 15 May 2017 at 14:24, Olivier Combe ***@***.***> wrote:
@josersleal <https://github.com/josersleal> that's exactly what they did,
the angular team hired me to improve i18n for everyone
But there is no way to integrate my lib directly into the core, after
working for 3 months for the core team I can tell you that Angular i18n is
much more complex and elaborate than my lib. It handles a lot of more
complex stuff, and it does it without all the bugs and shortcomings that my
lib has.
I understand that it's frustrating that the core doesn't evolve as fast as
what a library can do, but there are reasons for that, and the first one is
that you cannot implement something and change it whenever you see that you
forgot to include a use case. Everything has to be thoroughly planned and
thought.
Still, you will have most of the things that this lib can do in the core
in the future, but it might take a year before we get there unfortunately.
The good news is that it's going to be much better than my naive
implementation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#495 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC_xuFmBomH56LAVc_V9HpBThjWzEBR4ks5r6DX7gaJpZM4MxgA4>
.
|
Olivier has done a great job. The native Angular I18N has many advantages over all 3rd party I18N libraries.
Of course this approach has some limitations:
|
@ocombe : Is there any plan to add runtime language switching feature on i18n+AOT ? Right now application is planned to use ngx-translate over i18n because of the run-time switching constraint. |
Yes it's planned for the 5.x branch probably, not 5.0 though, we have too
much on our plate for that
Le mer. 2 août 2017 à 21:59, aghilesh <[email protected]> a écrit :
… @ocombe <https://github.com/ocombe> : Is there any plan to add runtime
language switching feature on i18n+AOT ? Right now application is planned
to use ngx-translate over i18n because of the run-time switching constraint.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#495 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAQMopxEs3C1QIGT2K4ezy93rJ_ss0s1ks5sUNU4gaJpZM4MxgA4>
.
|
How dificult is it to move from ngx-translate to angular i18n, I have already implemented ngx-translate so if I have to change is it too much work around ? |
is a totally different structure, however i don't see a possible reason for change ngx-translate for native i18n |
Does anyone know when this : will happen? |
It won't be for 5.0, it should be before 6.0 (so before march 2018). Unfortunately I don't have a more precise date |
@ocombe My application is currently using this library to do the translations, would you recommend switching to the angular i18n to not run into future problems? Would it be worth the time to switch over? |
if you can (meaning if you don't need translations in the code), it's definitively worth it yes |
Good to know @ocombe , thanks! |
I need your advice , i'm building a chat application (Web and Mobile app) .. So i'm confused about going ahead with using Angular i18n or Ng-Translator ? especially i saw your comment in github before that in March2018 Angular will release an edition that i18n has more features like dynamic load feature same like NG-Translator ..so i will be able to switch to another language without reloading the app (in realtime) is this correct or what ? i need your advice .. Thanks :) |
The way it's going, you'll never be able to dynamically change the language in Angular. It's clearly not a priority for Google and they don't think it's a problem if you have to reload the app completely to change the locale. |
@ocombe How about being able to do translations in code, is that likely to arrive soon to Angular i18n? |
Yes that's coming soon, we are adding runtime i18n in v6.0 and then code translations right after that (or maybe at the same time) |
The main problem with the fact that every language has their own app is it's really difficult to make the app share the same session. I'm actually facing this issue with angular 5 app combinnr with identify server |
@ocombe I am in the moment where i need to decide, should I use Angular i18n or ngx-translate. |
yes, I'm lobbying hard to get this, and we'll have it one way or another (either we support it ourselves, or we open the API and I'll make a lib for it)
there are a lot of websites for translators that you can use, some of them have a free tiers
if you can use the official implementation, then use that, it's more performant, the limitation is that it's limited to what is offered whereas with ngx translate you can always extend it via plugins, or even fork it if necessary |
Please do not add any new formats! You already have three: XMB, XLIFF 1.2 and XLIFF 2.0. Most other platforms have only one :-) Almost all online translation services claim to support XLIFF. The reality is that XLIFF is very complex format and Angular's extract tool can create pretty complex XLIFF. Especially if you have plurals, genders, links or inline formatting elements. In addition Angular XLIFF files contain many proprietary properties such as meaning and location. What I have noticed is that a generic XLIFF parser/scanner cannot properly handle Angular's resource files. This is why it is better that the localization tool uses a dedicated Angular parser that can property handle the resource files. But this is perfectly fine. The main task of a localization tools is to scan the source files and in that process extract all information that is needed. I am glad that Angular resources contain all the information needed to fully extract strings and enable continuous localization where translation and development can work independently to each other. |
@ocombe thank you so much. |
@ocombe is it possible to have i18n in angular libraries. you mentioned it in one of your talks. If so please suggest some sources for reference. |
You can add i18n to your libraries with the current v9 RC, just add |
@ocombe Does it mean that not only template text will be translatable but also dynamically passed messages? I have a variable in the component.ts and displaying it {{ variableName }} in the template. Would this work or would I need to put all the possible text in the template and use some ngIfs to display the correct one? |
yes, code translations work in v9 (what you call "dynamically passed messages"), the syntax is the following: const text = $localize`some dynamic text in your code with ${variableName}` |
@ocombe Thank you. One more thing, what about splitting the translations files per module? We have a shell app that uses many lazy loaded modules and would need to load only the translations we need. Is it possible with i18n? (When I try to find an answer it always mentions ngx-translate so sorry if it's described somewhere) |
Localize + Locl allows you to lazy load translations with a module when you lazy load a route, I'm working on adding an example to make it easier (and I'll also implement some helpers to make it smoother). |
@ocombe Thank you for the information and your work! |
@shral yes, you can do totally do that with just Angular i18n, but you'll need to use Locl to load the translation files at runtime (Angular i18n only allows you to load those at build time for now)... |
Thank you @ocombe for your response!
|
Hi @ocombe , I'm starting a large-scale Angular project from scratch and really want to get internationalization right from the start. From what I've read so far, a combination of |
@pdbruno yes, this is going to be supported like any other official package. |
I need to split a language file into several separate files. It is possible? |
@ocombe What would I need to include in the library setting to allow for this to work? Currently if i add |
|
So that works when my module is included in the project and using lazy loading, currently my problem is when the module is external to the main application and lazy loaded in (include into the project as an npm dependency) to allow use to version our modules. |
@kazeshini178 you can workaround this issue by declaring the export type TranslateFn = (
messageParts: TemplateStringsArray,
expressions: readonly any[]
) => [TemplateStringsArray, readonly any[]];
export interface LocalizeFn {
(messageParts: TemplateStringsArray, ...expressions: readonly any[]): string;
translate?: TranslateFn;
locale?: string;
}
declare const $localize: LocalizeFn; I think the best thing would be if these types were provided in a type package (I've made a feature request and PR for it), so you can just add this to your library's "types": [
"@angular/localize"
], |
@kazeshini178, there is some info in this issue on a different workaround, for now, to include this where you're using
But that will still not bundle the |
@sorohan, didnt even think of just "mocking" the interface that would be available main app. Thanks think that would work for me, will give it a go.
Thats perfect, and also what I would of expected |
@ocombe - just wanted to say thank you for this comment thread and all your hard work, this has helped clarify the right path forward for internationalization of my angular application. |
hi, My question is: is there any way to detect user preferred browser language, when i used the ngx-translate libraery it was very easy to do it, how can i do the same thing with i18n ? |
same question. |
Hello @AkourMohamed & @wzaieddev,
import concat from 'lodash-es/concat';
import filter from 'lodash-es/filter';
import first from 'lodash-es/first';
import intersection from 'lodash-es/intersection';
import isEmpty from 'lodash-es/isEmpty';
import isNil from 'lodash-es/isNil';
/**
* Get the first browser language
*/
getFirstBrowserLang(): string {
const cleanBrowserLangs = filter(this.getBrowserLanguages(), (lang: string) => {
return !isNil(lang) && !isEmpty(lang);
});
const browserLangs: string[] = uniq(
map(cleanBrowserLangs, (browserLang: string) => {
// We don't manage localisation yet (i.e.: en-GB => en, FR -> fr)
return lowerCase(replace(browserLang, /-.*/, ''));
}),
);
return first(intersection(browserLangs, this.availableLangs));
}
/**
* Get all languages of the browser
*/
getBrowserLanguages(): string[] {
const navigator: Navigator = window.navigator || window.clientInformation || null;
return concat(navigator.language, navigator.languages);
} |
Hi @dsnoeck, |
The simplest is to call it from your ngOnInit() method of the app.component.ts |
Hello every one!
and .html
I am looking for how can translate text in ts file, $ localize or ngx-translate can handle this problem |
@datnd-miagi I believe that adding public heading(): string {
if (this._paramType === "query") {
return $localize`Define a New Query Parameter`;
}
if (this._paramType === "header") {
return $localize`Define a New Header Parameter`;
}
if (this._paramType === "cookie") {
return $localize`Define a New Cookie Parameter`;
}
if (this._paramType === "formData") {
return $localize`Define a New Form Data Parameter`;
}
} |
I like ngx-translate more than the Angular i18n. At least what I've seen so far. To be honest I haven't tried it myself yet. Do I understand it correctly? You have to build the same Angular app for each language and e.g. use location URLs for your Angular app? If so, it's impossible to that for e.g. Cordova / Capacitor (Ionic) mobile apps using Angular. What do you mean with "reload" app? Reload on another URL with two letter code included (another path)? Or just use global settings storaged somewhere or use |
why should someone choose this package instead of the official i18n module ?
The text was updated successfully, but these errors were encountered: