Hi All,
I have a question about multilingual and internationalised (localised) applications, and how (if at all) this would affect API design.
If we take the example of a US news site which has a CMS, and we had a basic page structure with the following fields:
- heading
- author
- firstParagraph
- content
Now, if we want to provide the content in Spanish (language code "es"), what happens at the CMS side is we essentially create the page again with fields in the database specific to this language. So for Spanish, we would create something like:
- heading_es
- author_es
- firstParagraph_es
- content_es
Now a common way sites determine which language should be used is via URL parameters:
- website.com/ for the standard (english) version*
- website.com/es/ for Spanish-speaking visitors.
What I'm curious to know is, from an API perspective / from an edge management perspective, for each language, do you need to create an API to manage each version of the content?
- Articles API -
- Articles - Spanish API - api.website.com/v1/articles_es/
- ... API
- ... - Spanish API
or would you break it down by language?
- APIs
- Articles - api.website.com/v1/articles/
- ...
- APIs Spanish
- Articles - api.website.com/v1/articles_es/
- ...
When calling an API, how do you define which API to call? Do you (or can you?) use some sort of witchcraft on the back end which would support the routing of your URL parameters which could potentially give you something like one of the following
- api.website.com/v1/articles/
- website.com/api/v1/articles/
- website.com/api/v1/es/articles/
or
website.com/api/v1/articles_es/
Or is there some sort of hybrid thing
- api.website.com/v1/articles/
- api.website.com/es/v1/articles_es/
- website.com/api/es/v1/articles_es/
If it is unclear, please let me know and I can try explain further, but I didn't want to write a million words.
Cheer
David
LinkedIn
Twitter
