[Part 1: Database i18n as a Data Type Problem | Prototype Postgres Library]
In my last post (longer ago than I intended), I discussed the approaches I’ve come across to adding i18n to a database schema, and outlined my theory that the whole problem could be recast as one of data types. In order to explore how this would work in practice, I’ve put together a prototype “library” using only a standard install of PostgreSQL that shows how simple it could be, and why it makes sense.
[Part 2: Translated Text as a Data Type in PostgreSQL | Prototype Postgres Library]
The most obvious task when making any application multi-lingual is to make the UI translatable; there are absolutely tons of options for this, libraries in all sorts of languages, recipes, discussions, etc. But for many applications there’s another task, just as important, which is taking a database, and allowing someone to translate the data inside that.
There are various approaches to “database i18n” too – generally involving re-designing your schema in such a way that the translations are to some extent part of the “normalised” data. But these tend to make the schema somewhat unwieldy, and writing ad hoc queries and reports becomes tricky. So it occurred to me that if you treat i18n not as a schema problem, but as a data type problem, you could save some of that pain.
© 2024 Rowan's World Et Cetera
Theme by Anders Norén — Up ↑