Basic language support (i18n)

[CharlBest]

Basic support for multiple languages (internationalization - i18n)
Zero dependency, based on the implementation in Daisy UI docs

Usage:
It can be used in HTML in 2 ways. Either by using the component <T k="key" /> or by calling the translate function {@html $t("key")}
In javascript, you can also call the function as follows $t("key")

Language picker:

Example of translated text:

[scosman]

Oh cool! I won't be able to take a look until next week but excited.

• Can/do you auto-detect based on user locale/user agent?
• Can we make it super clean where it's off by default and easy to ignore. I think 90% of projects won't use this, but it is good to include for when they do need it. Related: prob should add a I18N.md file with quick instructions, and link to that from main README.md

[scosman]

Hey @CharlBest. I've been thinking about these PRs. They are really helpful features, and I could see a lot of people benefiting from it. They also increase the complexity for someone who doesn't want the feature, and increase the cost to maintain the template. I'm trying to think of a way to make them available, without taking the complexity/maintenance hit.

For example:

• I18n: is awesome and helpful. But now demo page has a toggle that doesn't actually work on most strings/pages. Adding content for every new string would add work to adding demo features (and real features). New forks would have to do work to pull this out if not needed right after they fork (and I imagine that's most forks)
• Dark mode: similar case. I put a lot of love in the default theme. Maintaining a second dark mode theme takes work. I'd like to say I used theme colours 100% of the time, but I'm sure I missed a few spots and there's maintenance cost to checking every page looks good in 2 modes (or we end up adding bugs).

Here's a proposal:

• We take these PR's into their own branches, not main. Call them something like "Optional Features". You can easily add these to your fork, but know that there's going to be some extra work getting them fully running (adding translations for i18n, defining/testing a dark theme for themes). We can define a branch prefix like reference/i18n, reference/dark_mode
• We add a section to the main branch README for "Optional Features", with descriptions of each, links to the branch and instructions.
• We add an "And More" section to the demo page that links to the readme section above. Something like "Reference implementations to get you started for internationalization, dark mode, and more"
• We add a new markdown instruction for each of these PRs / new branches with a basic explainer how to add it (add your translation files to X directory, run Y cli to check for missing string translations, define your dark mode theme in file Z, etc). Link to this in main branch readme change mentioned above.

Thoughts? Other ideas?

[owenversteeg]

That sounds pretty reasonable to me. Only thing is that it may not be a bad idea to combine multiple features into one branch? Reduces work a bit. I don't have a strong opinion on this though.

[scosman]

I’d lean to different branches to minimize work for people who want to use only one of them. That way they don’t need to parse it and delete some after the cherry pick.

@CharlBest thoughts?

[scosman]

@CharlBest thoughts? Would love to get these into the right place.

[CharlBest]

Sorry for only chipping in now. I was away on holiday for 2 weeks. I agree that not everyone will use these features which means they will have to remove unused code from the boilerplate/template you provide which isn't great so I think your suggestion makes sense. 😀