Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

i18n / l10n method? #96

Open
renyuneyun opened this Issue Aug 2, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@renyuneyun
Copy link
Contributor

renyuneyun commented Aug 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:

  • Translations are placed in different directories (or simply different filenames) for different languages correspondingly
  • Replace the text in the webpage template with variables (from Context), and load the variables dynamically (according to the language) in the rust code

There are two main questions before it can really be implemented into action:

  1. Where to place the tranlation file?
    1. Should they be placed within the directory of the webpage template; or should they be placed together?
    2. Should the translations (in the same language) be placed in a hierarchical manner, or centralized?
  2. How to name the translation text id?
    • When to use underscore _ and when to use hyphen -?
    • Or, either way?
@renyuneyun

This comment has been minimized.

Copy link
Contributor Author

renyuneyun commented Aug 10, 2018

So, after discussion with Ashley and some exploration, I think I have figured out a (personal-preferred) simple way to do this:

  • Use variables representing the translation sentences in the html templates
  • Use a Fairing to pre-process the template before handed to the Template implementation

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 common

Basically, they both ensure that the only thing needs to be changed for the routing functions is to replace Template::render() with a struct the i18n/l10n mod provides (and also the return type).

The fairing (let's call it I18N) will handle the on_response method. The language is figured out in this method (by querying the request parameter). The actual Template is then used to replace the response parameter (or we can customize the Template fairing...).

Method 1

Let the i18n mod figure out the translations needed, and provide necessary variables to the context of Template::render

This method consists of these steps:

  1. Scan the template file to get all variables needed. (Or generate this list in advance.)
  2. Query the fluent-rs context, and get the translated texts
  3. Add the translated texts to the context, and render the template

Method 2

Fill 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.

@renyuneyun

This comment has been minimized.

Copy link
Contributor Author

renyuneyun commented Aug 16, 2018

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 instanceof or is), so I can't find out a good way to do this.
One workaround I can think of is to test the URI against the routes to see if it is in the list. But this seems to be very unhandy... What's you suggestion(s)?

@VitalyAnkh

This comment has been minimized.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.