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

Make it translatable #21

Open
humitos opened this issue Aug 13, 2015 · 3 comments
Open

Make it translatable #21

humitos opened this issue Aug 13, 2015 · 3 comments

Comments

@humitos
Copy link

humitos commented Aug 13, 2015

Hi, I found this really interesting and I looked at the code to see how I can translate it but I found that it's done using docstring and I don't know if there is a way to make them translatable.

Do you know if it is possible to do it in the way that it's written?

Thanks,

@zerok
Copy link
Collaborator

zerok commented Aug 16, 2015

Hi :)

No, the current structure doesn't really lend itself to easily support translations. Of course, we could simple wrap the whole docstring around some gettext-function but that would end up being quite a mess.

A cleaner approach would perhaps be taking the module-path of each function and use that as key to look up the description text somewhere else.

That issue set aside, there is also the question of how to serve the translations. My first idea here would be to generate something like en.html, fr.html, de.html files and add a dropdown to all of them where the user can switch the language.

The big problem is still where to store the translations. @ulope do you have any ideas?

@ulope
Copy link
Owner

ulope commented Aug 18, 2015

I think serving the translated versions shouldn't be a big problem. From a quick google it seems to be relatively easy to get nginx to serve different static files based on the Accept-Language header. Adding a dropdown that sets an override cookie for the cases where the default fails should also not be that difficult.

As @zerok said it's much less clear where and how the translations should be stored. Since the traditional translation tools (gettext, etc.) are usually geared towards translating (relatively) short UI elements instead of actual page content they aren't very well suited for our site.

We could use some custom system that loads the translations from files (JSON, YAML or even Python come to mind) during generation of the output. That seems a bit cumbersome to me however.

Maybe the best solution would be to drop this "tests-are-content" scheme entirely and just store the whole content in some kind of structured file. We still could have tests for that via pytest's pytest_generate_tests hook.

@ulope ulope added the content label Aug 18, 2015
@ulope ulope added this to the 2.0 milestone Oct 12, 2016
@ulope
Copy link
Owner

ulope commented Oct 12, 2016

With the switch to Lektor we should have a much easier time with translated content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants