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

Help with ROADMAP - Site translation #1

Open
delthia opened this issue Sep 6, 2022 · 10 comments
Open

Help with ROADMAP - Site translation #1

delthia opened this issue Sep 6, 2022 · 10 comments

Comments

@delthia
Copy link
Contributor

delthia commented Sep 6, 2022

Hi,
I'm willing to help with creating and maintaining this site, as I don't know kotlin, therefore I can't help with the main project much (appart from translations and such), and think that I can help here, people who also would be willing to help and know kotlin, could do that with the main project, prioritizing it.
Having this in mind, I started by translating the website and getting it ready for other language's translations to be added, by putting all translatable terms from the page in the config. For now I haven't made a language switcher, but my changes are contained on my fork, and the changes can be previewed in this subdomain by going to any page, and adding /es right after the domain name and before the path (I put the preview in a subdomain of mine just because that was less work than making it work under a subpath in the github pages domain).

If you think that I'm going in the right direction and would like for me to continue with adding the language switcher and/or other task on the website's roadmap, as I'm completely open in helping with that.

Thanks

@patrickgold
Copy link
Member

Hi delthia,

thanks a lot for your offer to help translating and maintaining this site, really appreciate it! I had a look at your fork and you are definitely going in the right direction. I am completely fine with you adding the language switcher and helping with some of the roadmap items, this helps a lot! :)

Some thoughts about the localization management:

Hugo allows to have multiple configs in a config dir. Wouldn't it make sense to have one base config for the normal config stuff and then for each language a specific config file (e.g. strings.en.toml), wehre the strings are located? I think in the long run this will allow us to have automated tools such as Crowdin to manage the translations, especially because these tools are not capable of putting the translation back into the same file as the source.

As for the translation of the content pages I am unsure, your format looks ok to me, however I've also seen the content/<langcode>/<filename.md> structure in some other projects. Seeing as the actual URL scheme then already works like this, wouldn't it make sense to structure the content directory like this? As the default content layout en is used and all languages fall back to en if their own language dir has no corresponding translated content page.

Just some thoughts, if you have some other idea or approach I am open to them too :)

@delthia
Copy link
Contributor Author

delthia commented Sep 7, 2022

Hi,
I'll get going with splitting the configs in several files, as I do think that it is a better way to do things, as mine was just a quick way to see how I could get the thing working.

As for the translation of the content pages I am unsure, your format looks ok to me, however I've also seen the content/<langcode>/<filename.md> structure in some other projects.

That also makes sense to me, so I'll get that going too.

Now for a question: Should I change the index.html contents to all be variables?
While I do think that markdown files may easily be translated as they are, I think that it may be easier to get the mainpage's content in variables as it is an html file, and maybe, more prone to be broken by error in translations.

I'll also try to get going with the language selector. I'll try a dropdown made in html and css (I would like to avoid js if possible). With that, I'll keep track of my progress here.

Thanks

  • Directory-based translation
  • Directory-based configuration
  • Change index translation to variables
  • Get simple dropdown working
  • Style dropdown

@patrickgold
Copy link
Member

Now for a question: Should I change the index.html contents to all be variables?

Yep I think it is best to use the variables approach for all html files, and use the translate file directly approach for markdown content pages.

I'll also try to get going with the language selector. I'll try a dropdown made in html and css (I would like to avoid js if possible).

If you should need a little bit of JS it isn't too much of a deal, as long as no third-party JS libs are used. But a HTML/CSS-only dropdown would definitely be cool, it it is possible without too much issues.

@delthia
Copy link
Contributor Author

delthia commented Sep 7, 2022

Hello again,

Yep I think it is best to use the variables approach for all html files, and use the translate file directly approach for markdown content pages.

I've fixed that

If you should need a little bit of JS it isn't too much of a deal, as long as no third-party JS libs are used. But a HTML/CSS-only dropdown would definitely be cool, it it is possible without too much issues.

I've experimented with making it using the checkbox trick in css. For now, the dropdown part works, minus a few (quite a few, really) styling issues. I now have to get working to make it change to the translated version of the page the user is in, not just redirect to the translated frontpage, who it now does, and to make the selected language, either be marked in the dropdown, or just not appearing, but I'm trying to figure that out in hugo's templating system.

I've positioned it at the left of the 'visit github repo' button, but it should be a problem moving it elsewhere. I thought of putting it on the footer, which would work for the frontpage, but I'm unsure how practical it would be on longer pages, like the privacy policy.

The changes are live on my fork and on f.delthia.com

@patrickgold
Copy link
Member

patrickgold commented Sep 7, 2022

I've experimented with making it using the checkbox trick in css

Do you mean the trick where you have a hidden checkbox at the beginning of the document and you utilize the <label for=""> functionality for changing the display state of the dropdown?

I've positioned it at the left of the 'visit github repo' button, but it should be a problem moving it elsewhere. I thought of putting it on the footer, which would work for the frontpage, but I'm unsure how practical it would be on longer pages, like the privacy policy.

Tbh I think left of the Github repo link is best. What I had in mind for the future was to replace the "Visit GitHub repo" link in the header with just a clickable GitHub icon. This would save valuable space, especially on mobile browsers.

@delthia
Copy link
Contributor Author

delthia commented Sep 7, 2022

Do you mean the trick where you have a hidden checkbox at the beginning of the document and you utilize the <label for=""> functionality for changing the display state of the dropdown?

Correct. There is a hidden checkbox just beside the label, and I use #checbox:checked ~ .contents to toggle the visibility. Right now it hasn't got an animation, but I could try adding it after finishing the styling.

Tbh I think left of the Github repo link is best. What I had in mind for the future was to replace the "Visit GitHub repo" link in the header with just a clickable GitHub icon. This would save valuable space, especially on mobile browsers.

Then I'll leave it there. Putting a GitHub icon instead of the text can be done whenever you feel like it, its not a problem for me to change that if you would like so.

@patrickgold
Copy link
Member

The changes are live on my fork and on f.delthia.com

Just tested out your changes and it is going in a really good direction!

Correct. There is a hidden checkbox just beside the label, and I use #checbox:checked ~ .contents to toggle the visibility. Right now it hasn't got an animation, but I could try adding it after finishing the styling.

As I thought, this is a very neat trick which can be utilized in many ways to have cool features normally not possible without JS (had quite a bit of fun playing around with this functionality in my early days).

Putting a GitHub icon instead of the text can be done whenever you feel like it, its not a problem for me to change that if you would like so.

This is something which we can change easily later on, for now I think letting the link stay in place is best.

I'll let you continue work on this and respond to questions/give feedback when needed :)

@delthia
Copy link
Contributor Author

delthia commented Sep 7, 2022

Hi,
I have finishing doing everything on the list but translating the images alt texts. I'll get around to doing that when I get home tonight, and it will then be ready to be merged (if you aprove the changes)
After that, I will be available to do anything else in the site.

PS. I have done some simple styling on the dropdown, and I think is mostly ok, but definitely not perfect. I haven't animated the opening and closing, as I tried but wasn't able te figure that out.
Appart from that the templates all work.

@delthia
Copy link
Contributor Author

delthia commented Sep 17, 2022

Hi,
I just wanted to say that since I've had a bit of a busy week I haven't been working much into this, but I haven't forgotten about it.
I don't know if next week, but within the next two weeks I should work a little bit more into it, not as fast as those two days, but at a slower phase.

@patrickgold
Copy link
Member

No worries, currently my time schedule is also pretty packed so I fully understand your situation. Just take your time and ping me once you say it is ready for review again :)

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

No branches or pull requests

2 participants