Phoenix Localized Routes - Localized/multilingual routes in Phoenix

Yes, I saw the usage guide after posting here.
@BartOtten if you create this tutorial on the blog I would like to have some notification for this.
Thank you for your reply!

Looks great!

I wonder if @kip has already seen this! :blush:

Sure have! @BartOtten is doing an awesome job.

4 Likes

Hello, @kip I would like to know if you have a tutorial or video doing the internationalization of the app?
using the dependencies you have created!
I know one it is the cldr.

I would not dare to publish a localization lib without @kip’s blessing :wink: Therefor I asked him personally to have a look at the lib when it was pre-0.1.0. Dare to say we both share a vision.

As a result CLDR Routes and Phoenix Localized Routes have influenced each other for the better. Both coming from another direction and with other features, but both targeting improvement in localization of Phoenix apps.

Soon will pick up the conversation and check which area would add the greatest improvement to accomplish that shared vision.

4 Likes

I’ll be publishing my first livebook on this topic in the next week or so based upon my ElixirConf EU talk, and I have a few more in planning to follow that. I’ll post an announcement in the ex_cldr thread soon.

4 Likes

A small update has been published on Hex with a very limited change for end users. Therefor it became…

0.1.1

1. Enhancements

  • Fixed error reported by Dialyzer
  • Added typespecs
  • Modules split for better test experience

2. Breaking Change

  • Helpers.loc_route requires :loc_opts of type Scope.Flat.t() | nil instead of freeform map | nil

The README has been rewitten, hopefully better emphasizing the benefits and unique selling points of the library.

As I am not a native speaker nor the ultimate documentation writer, I wonder if someone could provide some tips for improvement.

Snip snip (a post ended up here instead of PM)

This is exactly what I need for my next project. Happy coincidence that you published it recently. @BartOtten Thanks :slight_smile:

1 Like

Version 0.1.2

  • Support Elixir >= 1.14

Hopefully I soon have some time to see how the new verified routes of Phoenix 1.7 can be localized, while keeping the same features (unobtrusive) as the helper variant.

2 Likes

Hi, I am having trouble to implement your library in Phoenix 1.7. The example_web.ex file content is very different from 1.6.

Please, could you add or remove in example_web.ex file if we want to use your library in Phoenix 1.7?

Also, I am using LiveView and I am not sure if it will automatically work for LiveView as well. Is this library compatible with LiveView or just the regular controllers?

—-snip—

Will look into it.

As for the last question: The lib is fully functional with Live View.

1 Like

Thank you.

You are really my last hope. I really need this functionality and don’t want to go back to Laravel and GitHub - codezero-be/laravel-localized-routes: A convenient way to set up and use localized routes in a Laravel app. to be specific. And having this functionality of your library is crucial for my website.

Progress on Phoenix 1.7 Verified Routes
I have two proof of concepts for a method to accomplish the same behavior as with ‘the old way’. Gonna trow it away and write the actual implementation.

Soon this lib will support localized (verified) routes using the new sigil method.

3 Likes

Progress on Phoenix 1.7 Verified Routes
Next week a new version will be released with support for verified routes!

It will feature a new config option to specify the sigil to use, allowing the developer to pick one not confliction with possible other used sigils.

Although Phoenix Route Helpers will still be supported, they are now fully optional.

afbeelding

4 Likes

Have a meeting to catch. So short notice: Verified Routes can be tested by the brave ones! I advice to clone the branch and try with a local path in mix.ex.

  • By default it uses ~l for localized verified routes, this can be set in the config. For example sigil: "q".
  • When setting sigil: "p". You have to set sigil_original: so the ‘former ~p’ is aliased. An info message will be printed at compile time to remind you and other developers about what sigil does what.
  • README etc not done yet. It’s an early commit.

Working Verified Routes Branch
Comments / bug reports can be put in the PR
Raw Example App with here the code changes for Localized Routes.

@kip: how about that? So much simpler than helpers!

3 Likes

0.1.3-rc.1

This version got released to Hex.pm and can be tested by adding/changing the dep in mix.exs:

      {:phoenix_localized_routes, "~> 0.1.3-rc.1"}

Call for testers

Please help me test this release by

  • upgrading your existing installation. There should be no breaking changes.
  • using this lib with Phoenix 1.7 (view Usage Guide @ Github)

Issues can be reported here


Changelog

Support Phoenix Verified Routes

Phoenix 1.7 includes a new Phoenix.VerifiedRoutes feature which provides ~p for route generation with compile-time verification.

This release adds support for Localized Verified Routes using sigil ~l. The sigil can be customized by setting the sigil_localized option in the configuration.

Overriding sigil ~p

The default sigil ~p used by Phoenix.VerifiedRoutes can be overridden by setting sigil_localized: "~p". When doing so, the original sigil is by default renamed to ~o. This can be customized by setting the sigil_original option.

Example

For an example of how to implement Phoenix Localized Routes using the new Verified Routes, have a look at the commits of the example app (branch bo/1.7).

Other changes

  • Use Phoenix.Component.assign for Phoenix >= 1.7

Showcase

The Example App is now live @ fly.io

4 Likes

15 posts were split to a new topic: Posts from phoenix_localized_routes

My dear lib followers,

Work at Verified Routes support urged me to refactor this lib. As a result…another Proof of Concept saw the light of day.

TLDR; let’s split up Phoenix Localized Routes - Localized/multilingual routes in Phoenix so developers can pick what features they need instead of importing one ‘do-it-all’, or write features themselves in a few lines of code.

But I have not forgotten you!

Routex has almost feature parity with Phoenix Localized Routes already, only one or two extensions yet to be written. Minor modifications might be needed to the backend module / configuration but it’s almost a drop-in replacement.

Routex` Assigns extension supports custom namespaces, so I chose @loc for the Example app. The Example app is actually just the Example App from Localized Route with a few tiny modifications; mostly ‘naming’ things which should be migratable with a search-replace.

I would like to gather feedback on the idea before any release! So please let me know what your routing needs are so I can see if/how that would fit in the Routex ecosystem; being an extension or part of the framework itself.

Link to Routex topic