BartOtten
Seeking your thoughts on Routex 1.2 pre-releases - localize Phoenix with minimal config
This thread once discussed Routex in it’s early form. It has been repurposed to gather feedback and discusses pre-releases.
Currently: pre 1.2.0
Target: localization with auto-detection of already used libs (Cldr, Gettext, Fluent), simplified setup, support for runtime dispatching and auto-plugs&hooks.
Official releases are announced at another thread: Routex - build powerful Phoenix routes: localize, customize, and innovate
Github: GitHub - BartOtten/routex: Build powerful Phoenix routes: localize, customize, and innovate
Main branch documentation: Overview — Routex v1.3.1
Most Liked
BartOtten
After a lot of refining and polishing, the rough edges are now a thing of the past. I’m thrilled to officially release Routex 1.0.0! ![]()
This marks a major milestone for Routex, solidifying its stability and readiness for production use. It has been quite a journey, shaped by valuable feedback and real-world use cases.
As the decision-making process comes to a close, I’ve also created a fresh thread in the Libs section to continue the conversation:
A huge thank you to everyone who provided feedback—it has played a crucial role in shaping both the design and documentation. Your insights and contributions have made Routex stronger, and I truly appreciate the support.
kip
@BartOtten well since Phoenix 1.7 is now out I have to get off my backside and finish up ex_cldr_routes to include localised VerifiedRoutes.
So I’m in for some collaboration as you proposed - and see if we can take your new library and integrate it.
BartOtten
A long time has passed but it was worth it! To celebrate a nice set of improvements, I released Routex 0.3.0-alpha.2.
As Routex was very much alpha, I took the liberty to break a few things for the better. If you used Routex already, check the Changelog where the breaking changes are listed.
Call for help!
I would love to collaborate on this lib! See some comments, PR’s or extensions from community members. The quality of this lib will benefit from multiple eyes. Feel free to contact me by personal message or other means.
Highlights
new! the process dictionary can be used to determine route branch
Routex solely used pattern matching on URL’s to determine which route branch (former scope) to use. Now the process dict key :rtx_branch -when set- overrides the URL matching.
new! extension Route interpolation
A route can be defined with route attribute interpolation. Any route attribute can be used!
live "/#{region}/products/#{language}/:id", ProductLive.Index, :index
new! module Routex.Matchable.
Uniform, better, faster, easier to use and it Just Works™. The functions in this module allow developers unexperienced with Macro’s and/or AST to create simple helper functions, while more experienced AST developers will be happy with the abstractions it provides as.
Matchables are an essential part of Routex. They are used to match run time routes with compile time routes.
This module provides functions to create Matchables, convert them to match pattern AST as well as function heads AST and to check if the routing values of two Matchable records match.
new! Module Routex.Branching
Provides a set of functions to build branched variants of macro’s. It’s interface is still a bit rough but it’s usable enough to build a new version of extension Verified Routes with it.
The renewed Verified Routes extension.
Using Routex.Branching it now also creates branching variants of url/{1,2,3} and path/{2,3} with, of course, configurable names. When the names of Phoenix are used an improved warning is displayed during route compilation.
improved: added the attribute ‘match?’ to the results returned by ‘alternatives/1’
The value is determined by a pattern match, so performance wise we’re good. It does make code clean.
<.link
:for={alternative <- Routes.alternatives(@url)}
rel="alternate"
hreflang={alternative.attrs.language}
patch={alternative.slug}
>
<.button class={ (alternative.match? && "bg-[#FD4F00]") || "" }>
<%= alternative.attrs.name %>
</.button>
</.link>
Example app
Updated to use the latest version.
Example App
Github Example App
BartOtten
Let’s talk about… v1.2.0-rc.0
With version 1.2.0 on the horizon I would like to collect additional feedback before the release is finalized. After all, nothing better than Elixir-community collaboration ![]()
Although the version bump is minor, the release itself is major! The full changelog is linked at the bottom of this post.
Much of the code base has been refactored, new extensions build a bridge between compile time and run time and the most common use case of Routex, localization, has become much easier with the new extension SimpleLocale.
Simplified Integration / Automation
Routex now streamlines integration with your Phoenix application by extending
its functionality from compile time to runtime.
- Call functions at runtime using (custom) Routex attributes
- Inline LiveView Hooks of extensions
- Inline Plugs of extensions**
Localize your Phoenix app
Routex.Extension.SimpleLocale is included as tech preview.
SimpleLocale was designed to provide a solution for the most common
cases of localization. Featuring automated Plug/LiveView integration, a small locales registry and very customizable locale detection at runtime (think Cldr.Plug.PutLocale on tweaker-steroids)
The registry is based on the official IANA registry. It only includes region and language identifiers (combined: locales) and their respective display names.
The runtime integration is not limited to any package and you can even have multiple locale backends at the same time, using different locales / language / region…
Routex using the buildin mini locale registry for button names and setting Gettext locale.

Docs, docs, docs
A much enhanced Usage Guide for getting up and running in no time.
The revamped Localize Phoenix Guide, so the issue this release began with could be closed
Speak up!
I hope to collect feedback on these new extensions / features! Let me know what you think as even a small comment might make a major positive impact. After all, this whole release was triggered by…
Localization guide is missing step to content translation (using Gettext)
@KristerV
![]()
Full Changelog
For a detailed changelog with all changes explained in depth:
BartOtten
v1.2.0-rc.1 has been pushed to Hex
Usually the changes within an RC series are minor. This time, not so much.
While tweaking the documentation of SimpleLocale for 1.2.0 release I decided to overhaul before it was too late and the project would be forced to do a breaking change in the next release. So I took it one step further…
Routex lowers the bar of Phoenix localization
I am happy to announce Routex arguably has the most comprehensive localized routes system for Phoenix, the most customizable locale detection and yet the easiest setup due to auto-detection of third-party localization packages.
Localize.Phoenix.Routes: Generate localized routes with ease
At compile time, this extension generates localized routes based on locale tags. These locale tags are automatically derived from your Cldr, Gettext or Fluent setup and can be overriden using the extensions options.
When using a custom configuration, tags are validated using a build-in locale registry based on the authoritive IANA Language Subtag Registry. It can also be used the lookup language and region display names.
Localize.Phoenix.Runtime: Plug and Play (aka: LiveView Hook)
A Plug and LiveView Livecycle hook to update the connection with locale attributes and store them in the session. Comes with sane defaults but is highly customizable, so each locale attribute (:locale, :region, :language) can be take from independent sources.
You can define a clear order of precedence for each attribute. For instance, you might prioritize a route’s :region attributes over the browser’s Accept-Language header but at the same time use the Accept-Language as the main source for :language.
Other
- fix: non-scope routes are lost (fix by @ken-kost)
- docs: improved Localization guides & Localize Modules-docs









