jamesarosen / ember-i18n Goto Github PK

For example:

Em.I18n.translations = {
  "link": "text/{{App.path}}/link"
};
App.path = "path1";
<a {{ translateAttr href="link" }}></a>

Would result:

<a href="text/path1/link"></a>

I think this is useful for binding property with emblem.js as I faced problem that cannot provide variable to translateAttr. i.e. :

{{t link pathBinding=App.path}}  // Works
<a {{ translateAttr href="link" pathBinding=App.path }}></a>  // Doesn't work

I am unable to figure out how to use translations with a computed property.

An example:

someProperty: function () {
    if (this.get('some_other_property')) {
      return 'lorem ipsum ' + this.get('some_other_property') + '  lorem ipsum';
    }
    else {
      return 'Lorem Ipsum is simply dummy text of the printing and typesetting industry.';
    }
}.property('some_other_property'),

Any help would be greatly appreciated.

Em.I18n.translations = {
  setup: {
    'title': {
      'header': 'Some text',
      'subheader': 'More Text.'
    }
  }
};

// Extend setup object. This can in theory reside in a separate
// file but for the sake of this example is in this file itself
Em.I18n.translations.setup.offers = {
  'title': 'offer title here',
  'option': {
    'label': 'soem more text here',
  }
};

In my handlebars where I look these up:

  <h5 class="title">{{t setup.title.header}}</h5> <!-- This is perfectly resolved -->
  <div class="descriptor">
    {{t setup.title.subheader}}
  </div>
  <h5 class="title">{{t setup.offers.title}}</h5> <!-- This doesn't resolve -->

Why is the setup.offers.title doesn't resolve? If I write it in the same object, then it does. This is very weird.

I've recently run into a case where view rendering crashed due to the way ember-i18n observed a binding. My console showed a "elem is undefined" error, referring to the result of the view.$('#'+elementID) call in the observer function. As it turns out, when this happened the view was just being destroyed, and invokeForState with '$' apparently returns undefined in this case.

This might actually be an ember issue (I'm using ember-latest commit 50de50e at the time of this writing) and not an ember-i18n issue, so I'll look into that some more. In any case I'm posting it here because fixing it for the latter is simple; check if elem is defined before checking elem.length.

Given

SC.I18n.translations = {
  'foo.bar' = "Foo's Bar {{bar}}"
};

Trying to evaluate the translation with a missing attribute raises an exception:

SC.I18n.t('foo.bar', { bar: undefined }); // BOOM!

This is particularly frustrating when using bound interpolations, since they can become undefined when any piece of the chain is removed.

I don't what to cross-post but if you feel that this should be posted again, please let me know.

The issue I came across yesterday is described on SO: http://stackoverflow.com/questions/17570552/how-to-avoid-computed-property-to-get-translation/17570976

Did I get it wrong?

Em.Button.reopen.call(Em.Button, Em.I18n.TranslateableAttributes)

Why not just

Em.Button.reopen(Em.I18n.TranslateableAttributes)

The bower.json states a jquery ~1.7 dependency.
I read the code and found jQuery.isFunction, this.$().attr() and view.$(). It should work with a newer jQuery version. Maybe just change it to >=1.7

James, nice code and eager to work with it.

Have you looked @ making a bpm package for this?

It looks like the coffee script wrapper prevents it from being executed when spade.required - not entirely sure.

I just included it for now in my source, but it would be nice to push this as a bpm package.

i18n wraps around the translated text in a or a tagName specified by developer. This span can potentially match a css rule and alter the original intended styling on the text. I actually hit. Is this a known issue?

In this particular case, I made adjustment to the css rule to get around. But wonder if there's better solutions. Thanks.

Would be great if a already build js version is available. I really would like to use ember-i18n, but I can't manage to build it on my system atm.

Thanks

Sometimes the line elem = view.$ "##{elementID}" triggers a re-render, which is deprecated (see below). This happens if the view is still in the buffer (view.get('state') == 'inBuffer').

I've tried to figure out exactly how to solve this, but haven't been able to. It says the implementation borrows heavily from the bindAttr helper, so perhaps we can look at how that code has changed (since Ember.I18n was written).

DEPRECATION: Something you did caused a view to re-render after it rendered but before it was inserted into the DOM. Because this is avoidable and the cause of significant performance issues in applications, this behavior is deprecated. If you want to use the debugger to find out what caused this, you can set ENV.RAISE_ON_DEPRECATION to true.

I am very interested in this project, since I18N support has not yet been added to SC2 by the SproutCore team.

However, I cannot find any license info, so I do not know if I can legally use this in my application.

Would you mind adding a license file in the top of your repository? If you don't care what kind of licensing you use, I'd vote for MIT or BSD-style licensing, as these are nonrestrictive.

Thanks!

https://travis-ci.org/jamesarosen/ember-i18n/builds

See #46

If the CLDR pluralization rules are bundled with this repository, we shouldn't expose CLDR.defaultLocale. @heartsentwined did this in #44 by introducing Ember.I18n.Config.locale. I might prefer Ember.I18n.locale or Ember.I18n.config.locale, but the idea of hiding this dependency seems good.

With some translation systems† there won't be any translation on the "naked" key (e.g. my.translation.key) and one must specify a pluralization, such as one or other.

E.g. the translation data will look like this:

{ my: { translation: { key: { one: "cat", many: "cats" } } } }

and lookups on my.translation.key would simply return the pluralization data, not a generic "cat" translation. In this particular case it would be nice if count always had a default value, e.g. 0 or 1.

I know that with the Em.I18n structure on the translation data (non-nested hash with key-value pairs) it's possible to keep a translation on the suffix-less key, but that isn't possible with all underlying translation structures (e.g. YAML files or JSON structures).

What are your thoughts on this?

† http://guides.rubyonrails.org/i18n.html#pluralization

Currently the {{t}} helper is passed a string key, I've recently had the need to translate based on the value of a property (in this case order).

For now I've just added a property on the controller for translatedOrder:

translatedOrder: function(){
    var order = this.get("order");
    return Ember.I18n.t("buttons.order."+order");
}.property("order")

That works fine, but nicer would be something like:

{{t order scope="buttons.order"}}

Obviously we'd then need to differentiate between property keys and string keys...

We could require that string keys are quoted, but that's not very backwards compatible and extra typing for the common case.

We could use a different helper for property translations? {{pt order}} or something better!

What do people think?

I am not that familiar with coffeescript so i couldn't figure it out by reading the code.

Why is Handlebars.Compile used? Kind of forces me to include the whole handlebars.js instead of just the runtime. Can we use pre-compilation?

Maybe i am missing something pretty obvious.

Note: There is no way to ask questions in github

Just like you can with Ember.View and Ember.Component, it would be nice to be able skip writing `Binding" when using interpolated values.

Example

{{t some.module.greeting nameBinding="firstName"}}

Becomes

{{t some.module.greeting name=firstName}}

I can send a PR if you agree that other people would like this feature too?

In some cases

{{t foo.bar.baz tagName="h1"}}

will generate

<h1 id="i18n-NaN">Foo Bar Baz</h1>

It's possible that this is only on older Ember versions.

This depends on https://github.com/jamesarosen/CLDR.js, which isn't an npm module. There's already a cldr project in npm, but it isn't browser-friendly because it requires a CLDR data XML file.

https://github.com/jamesarosen/ember-i18n/blob/master/lib/i18n.coffee#L121-L133 won't work because the view doesn't have a state property to compare with "inDOM".

@heartsentwined did this in #44. I'd like to port this to the current version.

I have a component that i want to pass translation as a property. Is there a way to do that, other than creating a property in the controller?

{{content-editable placeholder="post.text.placeholder"}}

lookupKey supports both dot keys ("foo.bar": "baz") and nested object keys ("foo": { "bar": "baz" }), but isn't explicit about which wins. Dot keys should take precedence. We need to document and test this.

@heartsentwined did this in #44. I'd like to port this to the current version.

If I have something like:

// I18n Setup
Em.I18n.Translations = { blah: "diddy" };

// In a template
{{view MyView nameTranslation="blah"}}

I'm going to end up with markup like:

<div class="ember-view" name="diddy">some content...</div>

But what if I want to use the translated attribute to populate the div's content? I don't want that getting serialized into my HTML, but from what I could see in the code, it will since it ends in Translation.

Is there a way around this currently?

If an application wants to precompile all translations and ship those down to the client, I18n.compile should be unnecessary. Currently, it's used for missing translations:

I18n.compile("Missing translation: " + key);

We should precompile that template and return a version that's bound to the missing key.

Currently, to use a translation as the interpolation value of another translation, you have to do it in JavaScript:

errorMessage: function() {
  return Ember.I18n.t('error_message', {
    modelName: Ember.I18n.t('user')
  }
}.property().cacheable();

It would be really nice to be able to do that in the template. Perhaps a syntax like

{{t error_message modelNameTranslation="user"}}

@heartsentwined did this in #44. I'd like to port this to the current version.

You mention in the README.md the CLDR.defaultLocale, but it is (now?) called CLDR.defaultLanguage

First of all, a big thank you to James for your brilliant work.

My question is about the prompt attribute of Ember.Select. I have tried the following:

{{view Ember.Select optionLabelPath="content.data.name" optionValuePath="content.data.value" promptTranslation="some.translation.in.german"}}

and defined,

Ember.Select.reopen.call(Ember.Select, Ember.I18n.TranslateableAttributes);

However, the resulting dropdown has an empty on the top, hence no prompt is displayed. Is "prompt" not translateable by ember-i18n?

Thanks.

I've read the docs and did not found how to set a current locale. Do I have to do something like:
Ember.i18n.translations = {
'en': {...},
'de': {...}
};
and then call them as {{t en.{...}} ? Is there a way to specify current locale to avoid that?

I have this custom helper method:

Ember.Handlebars.helper 'noneGiven', (attribute) ->
  if attribute == null
    t shared.none_given
  else
    attribute

Unfortunately, the helper doesn't have access to other helpers, such as your t helper. Is there a way to access it here?

Instead of declaring the translations like this:

Ember.I18n.translations = {
  'general.email': 'email'
  'general.givenName': 'First name'
}

I use:

Ember.I18n.translations = {
  general: {
    email: 'email'
    givenName: 'First name'
  }
}

And it apparently works. Is this offically supported? If not: Could you support it officially and mention it in the README.md?

It looks like the version of ember in bower no longer exists. I tried upgrading the the version to v1-pre4 in the components.json file but the test suite is failing. I'm not sure which version you want to target with this repo.

I'd like to see the ability to to:

{{#collection  contentBinding="Simplifi.Dashboard.FITListController" class="goal-list small"}}
  {{t MyI18nKey}}
{{/collection}}

where MyI18nKey="{{content.someProperty}}

currently in SC2 "content", "itemView" etc are available in the current context.

it seems like evaluating SC.getPath with the current context (around line 57) e.g.

currentValue = SC.getPath(context,bindPath);

should do it. I don't have this working yet, so no patch (yet).

I've tried {{t MyI18nKey contentBinding="content"}} but that doesn't seem to get it either.

After changing compilation process, change documentation, please.

I'm assuming this isn't possible, but I wanted to check. Is there a way to interpolate a helper, such as link-to? To do something like:

t organizations.versions.submitted userLinkBinding="#link-to 'user' user"

Currently the component.json declares and outdated ember version. The file should also be called bower.json now.

Why does the t helper render a tag by default? Would you consider a patch that doesn't render a wrapping tag unless the tagName option is provided?

How can I add html tag with action?

eg:

{{t new.user clickTag="<a {{action showPreview target='view'>Click"}}

When using the Ember.I18n.t function, the output is HTML encoded. This is a problem if a property that returns a result from Ember.I18n.t is bound in a template.

JS:

title: function() {
  if (this.get('state') === 'draft') {
    return Ember.I18n.t('invoice.index.title_draft', {contactName: this.get('contact.name')});
  } else {
    return Ember.I18n.t('invoice.index.title_draft', {contactName: this.get('contact.name')});
  }
}.property('state', 'contact.name')

Template:

<h1>{{title}}</h1>

Example of resulting HTML if contact.name is Billy's Billing:

<h1>Draft invoice for Billy&amp;#x27;s Billing</h1>

= The apostrophe is doubly encoded.

In my opinion, the result from Ember.I18n.t should not be HTML encoded.

Any ideas?

As suggested in dockyard/ember-easyForm#99 it would be nice to have the functionality of eachTranslatedAttribute exposed.

cf #65 and emberjs/ember.js@3327586

One suggestion: allow a separate Ember.I18n.HELPER_PARAM_LOOKUPS that defaults to ENV.HELPER_PARAM_LOOKUPS but can be set separately if need be.

I'm opening this as an issue so we can openly discuss how Ember-I18n will work in the future. As pointed out in #34, this project has a 1.x branch to support Ember 0.9.x and a 2.0 branch to support Ember 1.x.

This morning I decided I want to make some significant changes (improvements, I hope) to Ember-I18n. Because there will be breaking changes, my recommendation is that we work on them in a separate, long-lived branch and merge it into either 2.0 if that hasn't launched yet, or a new 3.0 version if it has.

The changes include:

Consolidation

Move pluralization rules into this repository. Everyone who's doing internationalization needs pluralization. Let's make it easy. We can expose two global functions that consumers can override if they want different pluralization behavior:

• Ember.I18n.pluralForm, which takes in a number and outputs one of [ "zero", "one", "two", "few", "many", "other" ]. This defaults to delegating to the current locale's implementation.
• Ember.I18n.fullTranslationKey, which takes in a key ("foo.bar" or "Save"), an optional key context (useful for differentiating "Save (ticket)" from "Save (user)"), and one of the Strings from pluralForm. By default, joins them, possibly with ".".

Number Formatting

Add CLDR-compatible support for number formatting, including percentages and currencies. Add two helpers, formatNumber and unboundFormatNumber.

Time Formatting

Add support for date formatting. Add two helpers, formatDate and unboundFormatDate. Each requires only a Date. Locales define default formats. Support standard Date formatting strings as well as "ago", which renders strings like "3 minutes ago." If tagName="time" is passed, render as <time datetime="2013-02-15T08:38">15 February</time>.

Language Packs

Separate localization information into language packs. The default build will include all language packs. For those who don't support every language and want to cut down on bandwidth, add a grunt task and a Sprockets class that makes it easy to build custom Ember-I18n releases.

Oursourcing CLDR Data

Currently, the only CLDR rules that Ember-I18n consumes are the pluralization rules from CLDR.js, which are hard-coded. We can rely on node-cldr or node-closure to pull the rules from the CLDR database for us and compile the language packs.

/cc @ebryn, @rlivsey, @morten, @hjdivad, @pjmorse

Upgrade the tests to use the latest version of Ember. Notice that ___Translation tests fail.

Ember now has the concept of keywords, such as controller and view. It appears that the usage of these aren't supported within bindings.

I'm not familiar with Rake but i'd like to help update the code for Ember 1.0