Community Feedback on i18n method naming

1

Should the I18N Service provide longer method names? I’ve noticed that the service provides really short method names which are hard to read and remember if you’re not overly familiar with

currently the service provides the following short methods

  tr(key: string | string[], options?: i18nextCore.TOptions): string;
  nf(input: number, options?: Intl.NumberFormatOptions, locales?: string | string[]): string;
  uf(numberLike: string, locale?: string): number;
  df(input: number | Date, options?: Intl.DateTimeFormatOptions, locales?: string | string[]): string;
  rt(input: Date, options?: Intl.RelativeTimeFormatOptions, locales?: string | string[]): string;

although it is obvious from looking at the signatures what these do, it’s a lot less obvious if you’re reading

i18n.tr('my.key')
i18n.rt(new Date())

my proposal is to add the following

  translate(key: string | string[], options?: i18nextCore.TOptions): string;
  numberFormat(input: number, options?: Intl.NumberFormatOptions, locales?: string | string[]): string;
  unformatNumber(numberLike: string, locale?: string): number;
  dateFormat(input: number | Date, options?: Intl.DateTimeFormatOptions, locales?: string | string[]): string;
  relativeTimeFormat(input: Date, options?: Intl.RelativeTimeFormatOptions, locales?: string | string[]): string;

I personally would also like to deprecate the short method names, and change the default alias of t to something more obvious like i18n. Given the ease of changing the latter, it’s not really necessary.

2 Likes
2

Thanks for opening this feedback topic. Since it’s not clearly mentioned, the valueconverters and binding behaviors, sharing the same method name, would they be changed as well?

Looking forward to the response from the community on whether things should stay as they are, rename existing method names with a breaking change or add new method names as aliases. With the last option also the question whether the original should have a deprecation notice.

Original background for the current naming convention of both attributes and method names is that they align with i18next.

1 Like
3

so… doing some research on something else, it appears that i18next uses t as their method, whereas our I18N service uses tr, so we’ve already deviated from the upstream, in this case. it’s also a bit unclear to me then why in the html it’s t and not tr.

@zewa666

the valueconverters and binding behaviors, sharing the same method name, would they be changed as well?

I would think so, but could you give examples.

1 Like
4

To give better context regarding the value converters and binding behaviors, I would like to point out that they share the similar name as in I18N service methods. For example, there is as nf value converter, and binding behavior as well. Using the same name brings uniformity if nothing else.

We can certainly use longer names but it will make the view/markup more verbose. As this is a matter of personal taste and coding style, there is no 100% correct solution. That’s why I am not inclined towards deprecating or removing the short names for that matter.

2 Likes
5

is there any possibility of adding aliases like you can with t?

1 Like
6

Good catch, dunno whether this used to be the naming convention back then in 2015 or simply because other libraries used it as well.

Aliases for vc and bh can be introduced as well.

2 Likes