normal sluice
“Hey, im looking into possibly adding translations to bruce baked right into it, full 10-language i18n (fr/es/de/it/pt/ru/pl/nl/tr + en) with bruce.conf + settings menu, by my calculations would use ~125 KB total.
Looking into the feasibility of it memory wise and if there's some interest into it, I'll work into geting that out.
normal sluice
Well i was thinking rather on an implementation with a settings menu that would load a .json of the language strings to override the english ones when another language is selected, a bit like many Android apps do it. Wouldn't be too memory consuming and I'm pretty sure that could fit on the ots partition still at least on the 8mb or more devices
storm rampart
This was discussed briefly in this issue. https://github.com/pr3y/Bruce/pull/1409#issuecomment-2985150388
If there is an implementation that has very little memory overhead then awesome.
This is a bigger issue on 4mb flash devices where we already remove features to get it to fit.
The .json idea is an interesting approach and would offload most of the translation data from flash memory. However what impact would this have on boot times/menu load times etc and also overall memory consumption at run time. Again we are pushing the limits on devices with no PSRAM. Adding a huge language pack to memory might be too much and looking up each string as it is needed might be too slow.
normal sluice
Well yes I am aware about that discussion and that specific one is about implementing translations on webui...and as it was well stated there, some more work is needed in order for there to work. My project would leave webui as is for now, english only but implement strings translations on the on-device ui only like the menus, the messages like "CC1101 NOT FOUND", SENDING COMMAND" etc which by using a .json or similar file aproach to replace those strings on boot, won't be too memory consuming. And it would be only implemented on devices with at least 8mb of flash and with spray (maybe later on tweak that to allow such devices to have it too but maybe not all 10 languages
And im very aware of the memory constraints we have on low end (memory-wise) devices. If i haven't got it wrong, there are around 290 strings to replace total but they are mostly short ones it wouldn't take as much space as you'd think with the aproach I have in mind
I can always go on with fork it and try that on to see how it works out if the interest is there
For the full translations pack it would mean a 122kb increase on total size and when loading it we would have a string on bruce.conf loading from.json for example or which language one sets which will charge that file from spiffs into ram which means an extra charge of only around 12kb. The other languages stay compressed into spiffs and don't get charged.devices like the tembed and stick- plus 2 can accommodate the full pack. Cardputer with launcher will get a trimmed out version (en, fr, es, pt). At least that's how I intend to implement it
storm rampart
There was a comment from bmorcelli which mentioned he was against translation (not just WebUI due to the memory issues.
The WebUI is already translatable at least in Beta since it now loads the html (and other assets) from LittleFS/SD card if they exist.
I would most probably go with a default English like it is now and if the language.json exists on LittleFS then load that. They can be downloaded manually or using the app store which I am working on.
It would be interesting to see a proof of concept without changing all the strings, maybe just the main menu to start.
normal sluice
Well i think mostly he was against changing the webui for now which anyway i don't intend to touch and like I said, it wouldn't take that much of a strain. But yeah I could do that or then open a fork and implement my changes and if someone wants to try it, fine and if devs later want to aprove it they can merge to dev. If not, we'll it can simply live on my fork as is. Would just be interesting to see how it would hold on but im pretty confident such an implementation wouldn't take a big toll on memory nor on ram
undone marten