Add i18n templates. #746
Add i18n templates. #746
Conversation
All templates can now have an optional language suffix. The loader will attempt to load a template with the language specified language as an extension to the specified name. For instance "index.html" with "en" as language will attempt to load "index.html.en" first, and fall back to "template.html" if the file cannot be found.
Internationalized templates can also be dynamically included in the templates. To do this, use a the template function {{ i18template . "included.html" }}
This function will also attempt to load "included.html.en" if the language is English, and will fall back to including "included.html" if the language cannot be found.
|
PS. I cannot build the current "develop" branch because goagain cannot compile on Windows, so I have only tested it on 0.10.0, and manually merged the changes. |
|
Only comment is that you should drop the toLower in the template lookup as we are no longer doing case insensitive template lookups, see #729 |
|
@notzippy - that would make my change weirdly inbetween, with new code behaving another way than the existing. I think that should be done once the case change is done. |
|
@klauspost I'm not sure this is the right way to approach i18n in views. Isn't it more common to have a message lookup method to get another languages version of the content? |
|
@brendensoares There is already a message lookup in revel. (http://revel.github.io/manual/i18n-messages.html) This allows developers to ALSO have specific templates for different languages. This can be seen in other popular frameworks as well (http://guides.rubyonrails.org/i18n.html#localized-views) |
|
@ready4god2513 what would the different be between |
|
Some languages you would want represented in a different structure, some are read LTR and other RTL |
|
@notzippy as long as there is a good use case for it, then I support it 👍 I just don't have a good use case myself since I have never coded an app in a RTL language. @klauspost can you outline a good use case from your point of view? |
|
Absolutely rtl is a great use case. And is something that I am actively working on. So +1 on that from me. |
|
Our two current usecases are EULAs and welcome messages, that are basicly big lumps of text that it doesn't make sense for us to use the translation system for. The EULAs differ from country to country, so a simple translation isn't what we are requiring. Another usecase is for heavily formatted text, since the current message system escapes HTML. |
|
@klauspost @ready4god2513 thanks gents. I'd like to test this out myself before we merge it, but all sounds good. |
|
After talking this over with @jeevatkm we feel it would be best to not merge this PR and instead include this functionality in the upcoming pluggable template engine. Thank you @klauspost for contributing this solution, it's a valid idea that we can use soon! We'll leave this PR open so we don't forget it. |
|
@pedromorgan ... you are closing because.....? |
|
See @brendensoares comment above and pluggable template engine |
|
Adding functionality to PR #1170, thanks for your input and design. |
All templates can now have an optional language suffix. The loader will attempt to load a template with the language specified language as an extension to the specified name. For instance "index.html" with "en" as language will attempt to load "index.html.en" first, and fall back to "template.html" if the file cannot be found.
Internationalized templates can also be dynamically included in the templates. To do this, use a the template function {{ i18ntemplate . "included.html" }}
This function will also attempt to load "included.html.en" if the language is English, and will fall back to including "included.html" if the language cannot be found.