I think this is a real showstopper, i18n is not ready to use until this is implemented.
E.g. I am not able to set translated validation messages in code

@Mattes83 Did you try this way?

<p [hidden]="!alertManagerRowForm.controls.sendTo.hasError('validateEmail')" class="help-error">
    {{ 'ALERTMANAGER__FORM__FIELD__sendTo__ERROR__validateEmail' | translate }}
</p>

😕 The documentation tells you how nice it is to have error messages in code and translation support requires anything in the template. Looks like there is more need for communication.

@marcalj I know this way...but I need to have localized strings in my ts files.
@manklu I totally agree

I think this is a real showstopper, i18n is not ready to use until this is implemented.
E.g. I am not able to set translated validation messages in code

Yeah same here, I've just switched from ng2-translate to Angular2 i18n as I prefer to use OOTB modules, and it's much easier to extract translations (ng2-translate is more time consuming IMO)
At this stage I cannot translate error messages raised from my services. No workaround either.

If someone want to start a design spec, it would be helpful (ie on Google Docs).

It would need to list all the cases. Quickly thinking about it, I see a need for

_.('static text');
_.('with {{ parameter }}', {parameter: "parameter" });
_.plural(count, {'few': '...'});
_.select(on, {'value': '...'});

Hi guys, great feature request 👍

Is there any suggested workaround to translate *.ts texts?

@fbobbio What I've been doing is create hidden elements in the template, ex.
<span class="translation" #trans-foo i18n>foo</span>.

Bind them using:
@ViewChild('trans-foo) transFoo : ElementRef;.

Then retrieve translated value
transFoo.nativeElement.textContent.

Looks retarded, but works for my needs.

As ng-xi18n already processes the entire TS-code, why not implement a decorator like @i18n() for (string-)properties? These could then be filled with the translated value, like @Input() is used with one-way data binding.
If the untranslated value cannot easily be extracted from code, just place it in the argument like so:

@i18n( {
  source : 'Untranslated value',
  description: 'Some details for the translator'
} )
public set translatedProperty( value : string ) {
   this._translatedProperty = value;
}

and feed the source into the property when there is no translation target.

This is an essential item in the whole internationalization cycle, IMO.

In my shop, we're accustomed to an "ng-xi18n - like" tool (an extension to xgettext) that crawls all types of source files looking for marked text to put into dictionary files for the translators.

I love the clean and easy i18n markup in the HTML templates, and I was expecting the same for Typescript code.

@vicb In addition to your use cases I'm thinking about possibility to support localization of interpolated string in TS code. However it's likely be needed to rewrite TS code to support such a scenario. Will it be a valid approach?

This is the primary feature stopping us from using the out-of-the-box approach to translation Angular 2 offers. We have many metadata driven components whose keys come from some metadata not stored in HTML. If we could translate via pipe or programmatically against the available TRANSLATIONS, we could get these components to show the proper strings.

In the mean time, we are limited to something like ng-translate because of this limitation.

The way I worked around this problem is by adding an empty 'lang' object in a service used throughout my application. I then apply a directive that reads all span in a div and store the value in that object. I place all my string in a template at the bottom of the page with an hidden property. The string is then reachable from the template or the component. It's ugly and you could easily overwrite an entry with the same id. But it's better then nothing.

SERVICE

@Injectable()
export class AppService {

    //Language string object.
    private _lang:Object = new Object();
    get lang():Object {
        return this._lang;
    }
}

DIRECTIVE

@Directive({
    selector: '[lang]'
})
export class LangDirective implements OnInit {

    constructor(
        public element: ElementRef,
        public app: AppService) {
    }

    ngOnInit() {
        let ele = this.element.nativeElement;
        for (var i = 0; i < ele.children.length; i++) {
            let id = ele.children[i].getAttribute('id');
            let value = ele.children[i].innerHTML;
            this.app.lang[id]=value;
        }
    }
}

TEMPLATE

<button>{{app.lang.myButtonText}}</button>
<div lang hidden >
    <span id="myButtonText" i18n="Test Button">Testing</span>
</div>

Hello @lvlbmeunier

Thank you for providing this suggestion for a workaround while we are waiting for the official implementation. I tried to implement your solution but I cannot seem to get the dynamic translation keys to get recognized. I was trying to do it like this:

<p *ngFor="let d of dataEntry">{{app.lang[d.name]}}</p>
<div lang hidden >
<span id="{{d.name}}" *ngFor="let d of dataEntry" i18n>{{d.name}}</span>
</div>

Those new keys don't show up in my xliff files. Is it possible to achieve this with your solution?

I never tried it but i'm almost certain that the build of the xliff file does not run code. Having dynamic value in i18n would be contrary to the concept. If you know for certain of all the name that would be in your list they should all be declared independently and not in a for loop.

Adding the keys manually works but it is impractical. In my case I get hundreds of text keys in need of translation from an API.

You can run your code and take the source and copy it to a file. The generation of the x18n file is based on static file.

With 4.0.0-beta you can assigning an id to i18n, for instance mainTitle:

<span i18n="title@@mainTitle">

With this we can, at least for the JIT compiler, create a dummy Component (it doesn't need to be added to the app html, just the app module) with all our "extra" translations.

For starters we'll add the providers not just to the compiler but to the app module as well:

// bootstrap.ts
getTranslationProviders().then(providers => {
    const options = { providers };
    // here we pass "options.providers" to "platformBrowserDynamic" as extra providers.
    // otherwise when we inject the token TRANSLATIONS it will be empty. The second argument of
   // "bootstrapModule" will assign the providers to the compiler and not our AppModule
    platformBrowserDynamic(<Provider[]>options.providers).bootstrapModule(AppModule, options);
});

Then we'll create a dummy component to house our extra translations, don't forget to add the component to declarations of AppModule. This is so that ng-xi18n can find the html (I think) and add it to the translation file.

//tmpI18N.ts
import {Component} from '@angular/core';

@Component({
    selector: 'tmpI18NComponent',
    moduleId: module.id,
    templateUrl: 'tmp.i18n.html'
})
export class TmpI18NComponent {
}

Add our translations to tmp.i18n.html:

<!-- tmp.i18n.html -->
<span i18n="test@@mainTitle">
    test {{something}}
</span>

Now we can create a service where we can fetch our translations:

import {Injectable, Inject, TRANSLATIONS} from '@angular/core';
import {I18NHtmlParser, HtmlParser, Xliff} from '@angular/compiler';

@Injectable()
export class I18NService {
    private _source: string;
    private _translations: {[name: string]: any};

    constructor(
        @Inject(TRANSLATIONS) source: string
    ) {
        let xliff = new Xliff();
        this._source = source;
        this._translations = xliff.load(this._source, '');
    }

    get(key: string, interpolation: any[] = []) {
        let parser = new I18NHtmlParser(new HtmlParser(), this._source);
        let placeholders = this._getPlaceholders(this._translations[key]);
        let parseTree = parser.parse(`<div i18n="@@${key}">content ${this._wrapPlaceholders(placeholders).join(' ')}</div>`, 'someI18NUrl');

        return this._interpolate(parseTree.rootNodes[0]['children'][0].value, this._interpolationWithName(placeholders, interpolation));
    }

    private _getPlaceholders(nodes: any[]): string[] {
        return nodes
            .filter((node) => node.hasOwnProperty('name'))
            .map((node) => `${node.name}`);
    }

    private _wrapPlaceholders(placeholders: string[]): string[] {
        return placeholders
            .map((node) => `{{${node}}}`);
    }

    private _interpolationWithName(placeholders: string[], interpolation: any[]): {[name: string]: any} {
        let asObj = {};

        placeholders.forEach((name, index) => {
            asObj[name] = interpolation[index];
        });

        return asObj;
    }

    private _interpolate(pattern: string, interpolation: {[name: string]: any}) {
        let compiled = '';
        compiled += pattern.replace(/{{(\w+)}}/g, function (match, key) {
            if (interpolation[key] && typeof interpolation[key] === 'string') {
                match = match.replace(`{{${key}}}`, interpolation[key]);
            }
            return match;
        });

        return compiled;
    }
}

Now we can do something like:

export class AppComponent {

    constructor(i18nService: I18NService) {
        // Here we pass value that should be interpolated in our tmp template as a array and 
        // not an object. This is due to the fact that interpolation in the translation files (xlf for instance)
        // are not named. They will have names such as `<x id="INTERPOLATION"/>
        // <x id="INTERPOLATION_1"/>`. And so on.
        console.log(i18nService.get('mainTitle', ['magic']));
    }
}

This is a hacky workaround. But at least we can leverage the translation file, get by key, interpolate and not have to have a hidden html in our application.

NOTE: the current @angular/compiler-cli NPM package of 4.0.0-beta has an incorrect dependency version of @angular/tsc-wrapped. It points to 0.4.2 it should be 0.5.0. @vicb is this easily fixed? Or should we wait for next release?

@fredrikredflag Awesome! And what about AOT?

@ghidoz AOT is another story. What we would like to do is to precompile all translations so we can get them by key. But since the ngc will replace all i18n with the correct translation we can't leverage it. Can't find any exposed options/properties that contains the parsed translations from ngc. We could use the same dynamic approach as for JIT by fetching the xlt file that way still provide it on the TRANSLATION token. However this goes against the purpose of AOT.

DON'T DO IT FOR ANY PRODUCTION APPS.

/// bootstrap.aot.ts
function fetchLocale() {
    const locale = 'sv';
    const noProviders: Object[] = [];

    const translationFile = `./assets/locale/messages.${locale}.xlf`;
    return window['fetch'](translationFile)
        .then(resp => resp.text())
        .then( (translations: string ) => [
            { provide: TRANSLATIONS, useValue: translations },
            { provide: TRANSLATIONS_FORMAT, useValue: 'xlf' },
            { provide: LOCALE_ID, useValue: locale }
        ])
        .catch(() => noProviders);
}

fetchLocale().then(providers => {
    const options = { providers };
    platformBrowser(<Provider[]>options.providers).bootstrapModuleFactory(AppModuleNgFactory);
});

@ocombe any news in angular 6?

It will not be in Angular v6, as explained above. We depend on Ivy which is planned for v7.

@ocombe may I suggest that you lock this thread, so that only the team can give meaningful updates when appropriate and we avoid the repetitive questions that you keep answering ?

My hack for use with the current Angular is using an ng-templateand create the embedded view programatically:

<ng-template #messagetotranslate i18n>This message should be translated</ng-template>

and then in in the component ts file:

@ViewChild('messagetotranslate') messagetotranslate: TemplateRef<any>;

createTranslatedMessage(): string {
  return this.messagetotranslate.createEmbeddedView({}).rootNodes[0].textContent;
}

The createTranslatedMessage method returns the translated message. Although I'm using the template to declare the message which is not optimal, this makes it possible for the CLI translate tool to register it in the xlf files, and I have a way of getting the translated message programmatically for use outside templates.

Hopefully the api will work for the routes as well ! For example

export const routes: Routes = [
 {
  path: '',
  component: HomeComponent,
  data: {
   title: i18n('Home'),
   breadcrumb: i18n('Home')
  }
 }
]

If this feature is released, would there be a significant change from the current i18n api? Would you recommend I start my project with i18n now or should I wait for the new i18n Api when Angular 7 gets released?

Any update When we will get run-time and dynamic translation support?

Runtime translations are done and merged (with ivy), but the compiler side is not finished yet.
I'm working on ICU expressions right now.
I haven't started to code the dynamic translations yet (service) but it's probably the next thing I'll do after ICU expressions.

@vincentjames501 Can we use i18n-polyfills with ICU expression?i have get no solution how to implement that

@ocombe, can you please clarify the difference between runtime vs dynamic translations?

there's probably no official denomination, but the way I see it is:

• runtime: translations are resolved at runtime, meaning not during build (like we do currently). It applies to all types of translations (templates, or in code)
• dynamic means that you only know what you want to translate at runtime, and you couldn't do it at build time. It mostly applies to "in code" translations, using a service. I guess that you could consider ICU expressions dynamic in the sense that they depend on a variable, but you can still compute all of the possible translations at build time because the number of cases is finite.

I postponed adding i18n support to the current project we're developing but we're getting closer to the release, any idea if this will be final in angular 7? Or should I consider other ways of adding translations?

@andrei-tatar i18n is working perfectly since Angular 2. The only downsides:

• No code translations (this issue) -> If you need it, use i18n-polyfill
• If you build AOT(recommended), the app has to be built for each language separately
• Since each app is built separately, when switching the language you have to reload the page

For the last two points you could use @ngx-translate instead. But it works differently from Angular's built in i18n so an later update could take some time. For the polyfill the update will be no time with probably no breaking changes.

@ocombe

How we can handle conditional operator using Angular i18n feature

*<div class="show-history d-none d-md-block" ngIf="isOk">

{{paymentMethod.historyOpned ? "Hide" : "Show"}} History

@shobhit12345

We use ngSwitch to template all messages, so we can attach i18n-tags to them individually.

<div>
    <ng-container [ngSwitch]="paymentMethod.historyOpned">
        <ng-container *ngSwitchCase="true" i18n="@@hide">Hide</ng-container>
        <ng-container *ngSwitchCase="false" i18n="@@show">Show</ng-container>
    </ng-container>
    <ng-container>&nbsp;<ng-container>
    <ng-container i18n="@@history">History</ng-container>
</div>

We use this method a lot to get around the missing dynamic translations. Given a bit of thought a surprising amount of text can be expressed in this way in templates. A common pattern is to have an array of messages, and then use this with ngFor and ngSwitch to template the messages, something like this:

ts

messsages = [ 'this is the first message', 'this is the second message' ]

html

<ng-container *ngFor="let m of messages">
    <ng-container [ngSwitch]="m">
        <ng-container *ngSwitchCase="'this is the first message'" i18n="@@firstMesssage">This is the first message</ng-container>
        <ng-container *ngSwitchCase="'this is the second message'" i18n="@@secondMesssage">This is the second message</ng-container>
    </ng-container>
</ng-container>

It's somewhat verboose - but it works!

If its done it wouldnt matter since we have to wait for Ivy to be complete, which is scheduled for Angular 7 (sept/oct 2018)

It's alraedy October. Do you think we'll have the new features by the end of October?

@lizzymendivil according to https://is-angular-ivy-ready.firebaseapp.com Ivy is 65% complete and it seems unlikely to be completed in only 30 days

Yes, ivy will not be finished in one month.

@ocombe can you please lock this down so only you can post updates. its a little annoying to get all the notifications of all the "when is it done?" comments

@ocombe it seems like Ivy is now at roughly 94%, do you think this may be ready by the end of the year?

I don't think so. Being feature ready and bug free (= usable) is very different. We're mostly working on fixing things right now.

@ocombe can we believe that i18n came before angular 8?

I don't think so. Being feature ready and bug free (= usable) is very different. We're mostly working on fixing things right now.

Ok, thanks for the prompt reply, much appreciated.

Any update @ocombe that by when we should expect ( Year End i see in last few comments ) the "Code Translation" part available along with "Template Translation" for I18N support with Angular? We thought to club ngx-translate-polyfill for the same along with Angular I18n feature but there also it seems xlf support is not available for merging existing xlf file by using https://github.com/biesbjerg/ngx-translate-extract CLI.

Thanks !

@Abekonge

We use ngSwitch to template all messages, so we can attach i18n-tags to them individually.
It's somewhat verboose - but it works!

Thanks for the suggestion! It seems the easiest to understand. My question is, do you still use this implementation in situations where the array has a "lot" of a values, like 10 or more? Seems like the code would get very bulky.