Make every string translatable / changeable

[mistermantas]

oh boy this is going to be fun.

if you have translation experience, give me a shout — either on this issue or by any other means.

[mistermantas]

This’ll be implemented as such;

data/
  lang/
    en.yml

{{ $lang := index .Site.Data.lang .Site.LanguageCode }}

{{ $lang.okMsg }}

[mistermantas]

This will now be in v3

if you are a translator — see this.

[mistermantas]

Lithuanian & English translations are finished, so I guess that’ll be the start!

[robsonsobral]

Hi! I just found your project and I'm analyzing it. Looks promising! Congratulations!

Why not to use real Hugo translations?

[mistermantas]

@robsonsobral Thanks for the nice words! I think native Hugo translations split sites up into two versions. I'm not sure if that's a good idea, frankly, coupled with the fact that I haven't used them.

Do you feel this would work better?

[robsonsobral]

I always use native Hugo translations even for single language sites. To split the site into two, you have to set two languages on config.yaml.

It´s really easier to write {{ i18n "okMsg" }} than to define language variables on templates.

And you can have multiple languages, if you want to.

[mistermantas]

Alright, I'm sold. You make a good point. I'm not really sure if it's as, let's say, easy to set up / change around like how it is now though.

The data folder can easily let you change around the language files - create new ones, override them, etc

The config file is long as is

[mistermantas]

Unfortunetaly it looks like this isn’t going to work. The native multilingual mode is not ideal for this situation.

Right now I quite like the structure of this project: data/ has the language files, config.yml holds most of site-specific options (like whether to build posts with dates in the future, obviously the site title, what systems need to be tracked, etc) and mumbling that into one seems a bit counterintuitive.

Thanks for the reply nonetheless.

[robsonsobral]

I guess I need to explain better.

Please, take a look at this project I worked on. The language files are all inside /i18n, not config.yaml.

Only in case you want to load more than one language, you need to set them on config.yaml, like I did on this other one.

Hugo stopped to recomend the /data for language translation a long time ago.

[mistermantas]

cState isn’t really a conventional Hugo website but, sure, I can give it a try.

Already, I can see the i18n folder’s language file is laid out differently. Case in point:

This is the current en.yml file:

thisIsDown: Down
thisIsDisrupted: Disrupted
thisIsNotice: Maintenance
thisIsOk: Operational

…and it would be a tad bit of work to re-do that. Not fun. But yeah, there’s quite a bit of cruft with the current solution.

[mistermantas]

I’ve given this a fair look — take a look yourself!