base internationalization

[sakydogalo]

change the name file spinner.svelte to Spinner.svelte << error build front-end and internationalization. I really like the project and am thinking about collaborating. I can handle the translation part. I've looked around a bit and did this. What do you think?

[theelims]

Hi, thank you for your interest in the library. And for your offer to contribute.

I'm on a business trip and can't go any deeper into the topic right now.

I haven't worked with generations bevor, but works that mean that every string and text in the fronted would need to be translated in one of the language files?

Cheers

[sakydogalo]

Hello, I'll briefly describe the work to be done (I would do it initially so you can check it, in the i18n branch).

Example in <div>:

<h2 class="card-title text-center text-2xl">
    Welcome to ESP32-SvelteKit
</h2>

Replace with:

<h2 class="text-center text-2xl">
    {$t('welcome')}
</h2>

en.js file:

export default {
    'welcome': 'Welcome to ESP32-SvelteKit',
};

es.js file:

export default {
    'welcome': 'Bienvenido a ESP32-SvelteKit',
};

... and so on for the other language files.

Example in <script>:

notifications.success('User ' + username + ' signed in', 5000);
notifications.error('Wrong Username or Password!', 5000);
console.error('Error:', error);

Replace with:

notifications.success($t('ntfc.succ.user') + username + $t('ntfc.succ.signed'), 5000);
notifications.error($t('ntfc.err.wrong'), 5000);
console.error($t('error'), error);

en.js file:

export default {
    'welcome': 'Welcome to ESP32-SvelteKit',
    'ntfc.succ.user':'User ',
    'ntfc.succ.signed':' signed in',
    'ntfc.err.wrong':'Wrong Username or Password!',
    'error':'Error'
};

es.js file:

export default {
    'welcome': 'Bienvenido a ESP32-SvelteKit',
    'ntfc.succ.user':'Usuario ',
    'ntfc.succ.signed':' logged in',
    'ntfc.err.wrong':'Incorrect username or password!',
    'error':'Error'
};

... and so on for the other language files.

Add to the svelte files for translation:

import { t, locale, locales } from '$lib/i18n/i18n';

I believe this can be automated and not written in all files.

I'm unaware of the size overhead this change implies.

In case of size overhead, there's another option, which I believe would be possible (I don't know how to do it): In the factory_setting.ini file:

[factory_settings]
build_flags =
  ; Language Settings
  -D LANG=\"en\" ;Pick the specific language
  ;Consequently
  ;Firmware_en.bin, Firmware_es.bin, ...

[theelims]

Thank you very much for the clarification.

The memory overhead would be my main concern. Especially as I haven't found a way to realise the build flag method you proposed. It works well for the C++ code, but not for Sveltekit.

My other concern is, that this enforces translations to everyone who is using this template as a basis for their own project. For this bare bones project it is not much of a problem, but I'm building several fairly complex firmwares with it. The proposed method with one translation file becomes then very large and hard to maintain.

Any suggestions how to address this?

[EvEggelen]

Not sure if my opinion matters here. But based on my experience as a newcomer with Sveltekit on the ESP32 I would be careful in increasing the complexity. It took me quite some time to fully digest how everything works and make changes to it ( maybe I also had bad luck that I was using a platform that was not compatible with Sveltekit at that time ).

Typically users would start editing this base project and then having multiple languages could add extra complexity. If you are planning a huge project that has a large community having multiple langues would be nice. But most of the project are smaller, so I expect this would be a drawback for them. .

[sakydogalo]

Thank you very much for the clarification.

The memory overhead would be my main concern. Especially as I haven't found a way to realise the build flag method you proposed. It works well for the C++ code, but not for Sveltekit.

My other concern is, that this enforces translations to everyone who is using this template as a basis for their own project. For this bare bones project it is not much of a problem, but I'm building several fairly complex firmwares with it. The proposed method with one translation file becomes then very large and hard to maintain.

Any suggestions how to address this?

I will soon finish the complete implementation of the frontend for multiple languages and send it. Once the first version is done, I believe it becomes easy to maintain.

[sakydogalo]

Not sure if my opinion matters here. But based on my experience as a newcomer with Sveltekit on the ESP32 I would be careful in increasing the complexity. It took me quite some time to fully digest how everything works and make changes to it ( maybe I also had bad luck that I was using a platform that was not compatible with Sveltekit at that time ).

Typically users would start editing this base project and then having multiple languages could add extra complexity. If you are planning a huge project that has a large community having multiple langues would be nice. But most of the project are smaller, so I expect this would be a drawback for them. .

Any opinion is always welcome in an open community for learning or teaching. On one hand, multilanguage support will make esp32-sveltekit more appealing to more people and will grow the community. On the other hand, users don't need to modify the multilanguage firmware, but the application they are designing (startdemo). In a few days, I hope to finish the basic internationalization and we can test it and give our opinions.

[sakydogalo]

Frontend translation almost finished, demo page still pending. Next step, I will make it possible to handle a single language (English/main) without errors due to missing translations. Languages with flags in the status bar or menu? Leverage TypeScript features to reduce transcription errors from JSON to Svelte in the translation (if possible).

[theelims]

You had been very busy.

To be honest, I'm still undecided whether I like the internationalization. On the one hand I think it is a good and inclusive idea.

On the other hand I see that this adds an enormous level of complexity to the project and will make it extremely hard to maintain on the long run. Especially with those niche languages like Galician. Also it will make it much harder for most people to adopt the front end for their needs.

[theelims]

Internationalization will not become a core feature as it will bloat the code on a very constricted device and will complicate the implementation.