belaustegui

belaustegui OP

Hi again! We got a new version of Trans!! :slight_smile:

The only change in the new 2.1.0 version is the support of Ecto 3.0 as a dependency. Client code using Trans should keep working as usual without any modification.

You can see the release notes on GitHub or fetch the new version fron hex.pm.

As usual, any comments, suggestions, issues or pull-requests are more than welcome!
Love :heart:

5
Post #21
sfusato

sfusato

Awesome. Just upgraded. The only change in my case was dropping off {:ecto, "~> 3.0", override: true} from my deps. Thank you!

0
Post #22
belaustegui

belaustegui OP

Hi everybody! I’ve just published a new release of Trans!

Thanks to @sfusato and @gorav the main change in this 2.2.0 version is that the locale can now be passed as a string, so we can use Trans.Translator.translate/3 with the value returned by Gettext.get_locale/0 :raised_hands: For example we can now write something as:

Trans.Translator.translate(article, :title, Gettext.get_locale())

This release also removes Faker as a dependency, updates ExDoc and removes support for Elixir versions older than 1.6 (which are not officially supported by the core team anymore).

You can see the release notes on GitHub or fetch the new version from hex.pm.

As usual, any comments, suggestions, issues or pull-requests are more than welcome!
Love :heart:

3
Post #23
kip

kip

ex_cldr Core Team

This is great to see, it makes it really easy for ex_cldr users to get in on the party too. For example:

Trans.Translator.translate(article, :title, MyApp.Cldr.get_locale().cldr_locale_name)

One thought for your consideration is locale naming.

  • A locale name in Gettext is: arbitrary strings as long as they match a directory name which is no issue for simple locale names like es. But it does create ambiguity when you want Spanish as spoken in Chile. Is it es-CL or es_CL or es-cl or ES_CL?

  • Posix locale names use _ as the separator between a language code and a territory code. Therefore es_CL. Posix locale names aren’t full language tags (in the Unicode sense) but of course they are very common and fulfil most requirements.

  • Unicode’s CLDR says The "-" and "_" separators are treated as equivalent, although "-" is preferred. Therefore es-CL.

  • BCP47 is the formal definition applied for locale name in ex_cldr and therefore uses the “-” in its canonical form. Whereas ICU, a common CLDR implementation, uses “_” since its primarily targeted at the posix-compliant world.

  • Last point, All identifier field values are case-insensitive at least as defined by ICU and CLDR.

I’ve found this to be a source of occasional confusion: Do I use - or _? Is es-cl the same as es-CL? Since both Gettext and CLDR allow either I force one canonical approach internally ex_cldr.

I like to suggest Trans consider the implications of this too since it now takes a string locale name key. Perhaps:

  • At least treat - and _ as equivalent
  • And desirably treat all identifiers as case insensitive
    (which also happens to be what I do in ex_cldr). This might have backward compatibility issues since its easy on a case insensitive file system (most Mac file systems, Windows) but not on Linux and friends.
  • Or maybe just be really clear about the canonical form you expect and make it the developers concern.

Thanks for a great library, hope this wasn’t too much of a dive into esoterica!

2
Post #24
belaustegui

belaustegui OP

Hi again! I’ve just published a new release of Trans.

Thanks to @sfusato, @RxAssim and Philipp Waldmann for their awesome contributions:

  • Translations can now be stored using embedded schemas. This is now the preferred way of using Trans since it provides stronger, explicit and easy to use translations. The old plain maps are still supported, of course.
  • Entire structs can now be translated using the new translate/2 function
  • We can automatically raise an error if a translation does not exist by using the new translate!/3 function.
  • Documentation has been greatly improved to showcase the new structured translations approach and to include specs in the public functions.

This release also updates the Trans dependencies to ensure clean compilations without warnings and requires Elixir 1.7 or higher.

You can see the release notes on GitHub or fetch the new version from hex.pm.

As usual, any comments, suggestions or pull-requests are more than welcome.
Love :heart:

7
Post #25
belaustegui

belaustegui OP

Hi again! I’ve just published Trans 3.0.0.

Thanks to @kip , Kian-Meng Ang and Daniel Tinoco for their awesome contributions:

  • Unstructured translations are not supported anymore. They have been discouraged for some time but this release cuts them out in favour of structured translations using regular schemas as they provide much more explicitness and robustness.
  • The new Trans.translations/2 generates the translation code for you. For most cases this macro will generate the required nested schemas so you don’t have to write the code manually. If you prefer to write the translation schemas yourself you can always continue to do it just like you did before.
  • Locale fallback chains are now supported. When translating a struct or querying the database you may provide a list of locales instead of a single locale. Trans will fall back to the next locale in the list until it finds a translated one.
  • Docs and tests have been improved to showcase the new functionalities.

This release also updates Trans dependencies and bumps the minimum Elixir supported version to 1.11.

You can see the release notes on GitHub or fetch the new version from hex.pm.

As usual, any comments, suggestions or pull-requests are more than welcome.
Love :heart:

3
Post #26
— All posts loaded —