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

Change localization process #244

Closed
erciccione opened this issue Sep 15, 2019 · 6 comments
Closed

Change localization process #244

erciccione opened this issue Sep 15, 2019 · 6 comments

Comments

@erciccione
Copy link
Contributor

This is something we briefly discussed in the past days. The way the website is translated now is a beginning, but not optimal. Some translations are in html files, other in yml and some sections need to be updated for each language. That makes working on translations hard and unmaintainable in the mid-long term.

As i suggested in past i think we should implement a better workflow. I think using the jekyll-multiple-languages-plugin to manage the localization of the webste is the way to go.

SInce this approach received some positive feedback in the past I already started to work on this. It will take some time because requires a complete change of the structure of the repo and of most of the files, but after, the maintainance of the repo will be easier and the structure will be consistent for all languages.

Feel free to assign this issue to me

@wiz
Copy link
Contributor

wiz commented Sep 15, 2019

Does this plugin support country-specific locales?

@m52go
Copy link
Contributor

m52go commented Sep 16, 2019

@erciccione this could be very good, I think, as long as:

  1. you think the effort is worth it...it seems like translations are a bit of a mess to maintain regardless, and changing the localization process probably only makes sense if it's significantly better than what we have now.
  2. this plugin can be made to accept locales, as we discussed in [WIP] Remove flags in locale selector #243. I know you're not a fan of that direction, but that's currently the way we'd like to go.

@erciccione
Copy link
Contributor Author

The plugin doesn't care. It only changes the structure, we can use any language/locale we want. To clarify: My intention is not to revert or ignore the consensus reached in #243. A collective decision is law in an open source project, even if i was against it.

you think the effort is worth it...it seems like translations are a bit of a mess to maintain regardless

If there is an interplanetary truth, is that translations are a mess to maintain :), but as i briefly explained, i think this plugin is really necessary. The present way is unmaintanable in the long run and touches too many files. It will only only get worse with every new language. This new way of doing things will make everything much easier for both maintainers and contributors.

@m52go
Copy link
Contributor

m52go commented Sep 16, 2019

Great, I figured that, but just wanted to make sure. Assigned this issue to you :)

@erciccione
Copy link
Contributor Author

I'm not interested in working on this anymore. See #260 (comment).

@erciccione
Copy link
Contributor Author

On a second thought, i think it's better to reopen this issue. This repo is still in a very bad shape and if new languages are added with the current system, they will only make the repository heavier and more messed up than it already is. A refactor is very needed and somebody else could be willing to pick up this task.

@erciccione erciccione reopened this Oct 20, 2019
@gabernard gabernard closed this as not planned Won't fix, can't repro, duplicate, stale Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants