Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upi18n / l10n method? #96
Comments
This comment has been minimized.
This comment has been minimized.
|
So, after discussion with Ashley and some exploration, I think I have figured out a (personal-preferred) simple way to do this:
The routes (functions) don't need to know anything about the language preference -- it is handled by the Fairing. Until here, Ashley and I have a consensus about the design during our discussion. However, the way how fairing and/or template works make this a little tricky and we must solve the problem. Problem Because we are going to fill in the translation sentences in the rust programme, the code must know what texts are going to be filled in (or all available texts, which is too costy) to the template. We have the plan to let the fairing to handle this, so we must "allow" it to do so. I have two proposals for this to work, each has different work to be done. What they have in commonBasically, they both ensure that the only thing needs to be changed for the routing functions is to replace The fairing (let's call it Method 1Let the i18n mod figure out the translations needed, and provide necessary variables to the This method consists of these steps:
Method 2Fill in the templates in advance to server execution, and just render this template instead This requires to fill in the templates with the translated texts in advance, for each language. The fairing will just render these templates instead, rather than the original templates. |
This comment has been minimized.
This comment has been minimized.
|
Ok, there is one more question / problem for the implementation using fairing. This is about rust, not rocket. For whichever (of the two above) method, a fairing will be used in the halfway to intercept the response (and maybe also request). However, since not all routes will be i18n-ized (e.g. favicon), there is a need to test the route to determine whether this should be extra handled by the i18n fairing. However, as far as I know (and searched), rust doesn't support type testing (like |
ashleygwilliams
added
dev
content
labels
Nov 12, 2018
This comment has been minimized.
This comment has been minimized.
VitalyAnkh
commented
Dec 2, 2018
|
The new website will be shipped on Dec. 6 so how can we add i18n content now? I’m very glad to add Chinese translations but I don’t how to contribute. |
renyuneyun commentedAug 2, 2018
So, yeah, as it seems explicit the website needs to be i18n / l10n, there must be the backend support for that.
Presumbly this is done by using fluent-rs, and so the Fluent Translation Language will be the method of defining translation language.
I can imagine some behaviours which probably be good:
Context), and load the variables dynamically (according to the language) in the rust codeThere are two main questions before it can really be implemented into action:
_and when to use hyphen-?