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

Dart internationalization library is an unusable mess - It needs a total redesign #15796

Closed
DartBot opened this issue Dec 26, 2013 · 9 comments
Closed
Labels
area-pkg closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Dec 26, 2013

This issue was originally filed by @Emasoft


Internationalization in Dart it's a mess, and it's a big stumbling-block.

Read the following article for an in depth explanation:

http://japhr.blogspot.it/2013/12/code-generation-and-polymer-i18n.html

We are at the verge of 2014. We need a modern internationalization system integrated right into Dart.

Those are the features we need:

  • TRANSPARENCY : Once you write the code for a web page in a certain language, you must be able to localize it without going back and change anything of the original dart or html code. Switching between languages should be independent from the structure or the code of the page. For example a single call to a method at page load should localize automatically all strings and numerical values behind the scenes.
  • INTEGRATED : Localization data should be integrated into the components (both for native or Polymer elements). Localization data should be portable like the elements and recognized at the language level. Missing or partial localizations should be marked as error. All international standards of metric units should be included and automatically parsed from strings, dates or numbers, with explicit conversion methods when the identification is not possible.
  • AUTOMATED : The right localization, if present, should be automatically activated according to the browser language or location. The existence of localization data should be enough to make the localization happen. An explicitly statement must be provided to disable this feature. In this way just copying a new localization file for a specific language in the same folder of the web app sources should activate the localization, without changing any other file.

Thank you.

@sigmundch
Copy link
Member

cc @alan-knight.
Added Area-Pkg, Triaged labels.

@alan-knight
Copy link
Contributor

This isn't very specific, and seems to cover quite a lot of separate points.

The main point of the linked article (the link doesn't work for me, but the article is easy enough to find) seems to be that the intl package needs better documentation. It's also incomplete in that it isn't hooked up to a real translation system so you end up hand-writing JSON files in its own custom format, which isn't that useful, but it's mostly there as a hook for tests. That, combined with the lack of visible documentation obviously made it difficult for the author to figure out.

For the other points. Transparency:
How is this different from what the package does now? The intl package generates code, but the application code does not change with additional translations, it just needs the single import of messages_all.dart.

But maybe what you mean by this is that you'd like an application written without any idea of internationalization should be able to be automatically localized by extracting all strings from the application. That seems very difficult to do, and does not necessarily yield the correct results if done. Typically doing translations requires additional information along with the basic strings, particularly when there are values interpolated into them.

Integrated:

 a) Localization data should be included with components and failure to provide it should be an error. I don't think I agree with this. Feedback from users has typically been that the text in widgets is specified by the application. e.g. if I have a button widget, the button doesn't know what its text is, the application provides that. I don't know what "recognized at the language level" means, but anything that requires language changes would be difficult to implement in the short term.

 b) A unit system and data for all standard units should be included.
Units seems to me like a separate package. In web applications you don't want to download more than you need. The Intl package has the ability to parse numbers and dates in the format of various locales. Converting between SI units, while useful in some contexts, seems like a separate concern.

Automated:
a) Get the locale from the browser. The intl package includes functions to automatically set the locale from the browser. But that isn't necessarily the locale you want to use. For example, the user may have a locale set on their account, and want it used regardless of what country they're in.

b) Picking a locale without an explicit operation. Knowing if a localization file exists requires a round-trip to the server, so it's an async operation. So we require it to be explicitly done so that the application has something to wait on, and the ability to find out if the locale is available or not.

c) Not changing other files. For numbers and dates we can either get the localization data from a file or we can have it imported as code. With the hopefully upcoming ability to do deferred loading of code that seems preferable to loading the data from files, so that is the only operation that's been implemented so far. I don't think there's any reason we couldn't also be able to load data from files.


Removed Type-Defect label.
Added Type-Enhancement, Library-Intl, NeedsInfo labels.

@anders-sandholm
Copy link
Contributor

Removed Library-Intl label.
Added Pkg-Intl label.

@alan-knight
Copy link
Contributor

I don't seem to be getting any more information on this and it's not clear to me what action to take on this.


Added WontFix label.

@DartBot
Copy link
Author

DartBot commented Jul 29, 2014

This comment was originally written by @Emasoft


As usual the community was forced to solve the problem with an hack.

Here is an implementation of Gettext ( https://en.wikipedia.org/wiki/Gettext ) for Dart that solves with a workaround the localization deficiencies of Dart:

The package is called "l10n":
http://pub.dartlang.org/packages/l10n

There is a discussion going on this on G+:
https://plus.google.com/u/0/+MikeMitterer/posts/VRjh7uXJzK5

It would be much better to implement a native solution like this into Dart.

@alan-knight
Copy link
Contributor

OK, but what do you mean by "like this". This seems quite similar to the mechanism in the Intl package already. It looks like you do the extraction of the messages yourself, it uses a different file format, and it generates all of the translated messages into a single library instead of multiple libraries with a single import point. What is it you're looking for a native mechanism to do differently?

@DartBot
Copy link
Author

DartBot commented Mar 28, 2015

This comment was originally written by hangglide...@gmail.com


@alanknight from your words it seems everything is simple. If Intl so good, please could you give the resource (I do not mean scattered intl readme.md from pub) where we can get the information how to work with Intl breaking messages into separate files?

As I can see there is still no information regarding official i18l and l10n tutorial: dart-archive/www.dartlang.org#728 (

@alan-knight
Copy link
Contributor

What sort of things are you looking for in the README but not finding?

There's an example with an emphasis on using Polymer at https://github.com/dart-lang/sample-polymer-intl but it's more about using the translated messages in a custom element.

There's an example in the example directory of the Intl package which you can see on https://github.com/dart-lang/intl/tree/master/example/basic It doesn't do the translation, it has the hard-coded translated versions there, but is an example of how the results are used.

But essentially the steps are.

  • Write your messages using Intl.message.
  • Run the extraction code extract_to_arb.dart as described in the README "Extracting and Using Translated Messages" to get an ARB file.
  • Translate the messages somehow. Uploading them to Google Translate is one easy way. Have one ARB file per targetlanguage.
  • Run generate_from_arb as described in the README.
  • Import the generated messages_all.dart in your program.
  • Determine which locale you want. You can get the browser locale as described in the "Current Locale" section of the readme, or use some other source.
  • Call initializeMessages(locale), which is an async operation. Once it completes, if the Intl.defaultLocale is set to locale, then messages will be shown in that locale, unless a different locale is specifically passed to the call.

@DartBot
Copy link
Author

DartBot commented Jun 5, 2015

This issue has been moved to dart-lang/i18n#341.

@kevmoo kevmoo added closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug and removed priority-unassigned labels Mar 1, 2016
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-pkg closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants