Another point at my whish list is about ephemeris.
One can put a special file to $OPENHAB_CONF/services/ to get translated Names of holidays.
BUT: As this is only active in displayState, there is no easy way to get the translated Name as a pure text.
Also, I experienced some hickups with the translation (and it would be nice to be able to configure that part properly anyway…)
What about the option to chose the language per user?
Think about Families with multilingual background.
But of course this would be a really big bite to eat…
Weird thing to say, almost as if you expect some sort of agreement or a written process regarding that…
I’m Portuguese, I speak English at home, my parents speak Portuguese, my wife sometimes switches to French, the guy that sells me pastries speaks Spanish, my hairdresser speaks some funky kind of Brazilian, and my son is 20 months old now and making his own language right now.
don’t tell me people in Germany only speak German
Sure you can assume that everyone speaks the same language, but from my list above, only three speak English:
Me, my wife and my father.
My kid only says “this”. And throws bottles at me.
So that would leave basically everyone else locked out due to lack of accessibility basically.
If I switch to Portuguese, which you can argue would be the logical thing to do, now I’m pulling my hairs out, my wife wants to divorce me, and my father is laughing is ass off. And it’s my home so I call the shots.
If I could I would have the presence widget with my parents faces there so that they could click on them and have the entire dashboard, ui, language etc change per that person. Then later maybe use face recognition for that maybe? That would be hella sweet, and I think that this kind of thing is exactly what home smart automation should tackle - the human condition (not necessarily this example now, but in general.)
The base might not be too hard to implement. A language parameter to the url might override the openHAB configured language.
But it was not (yet) designed with this, so there will probably be some challenges.
Now that I think of it, I remember basicUI does something related to the language based on the browser. @Lolodomo im I mistaken?
I believe you’re mistaken here.
The upgrade process should be keeping the installed bindings installed. If not, open a bug report.
Signal however is not a regular binding AFAIK but some file you had manually injected.
And Ephemeris is in core.
Marketplace bindings are deinstalled during upgrade intentionally (or at least should be, not sure what’s the current status here) because there is no way for openHAB to get the correct version of the add-on automatically.
IIRC Main UI uses the browser language for REST API requests, but the configured system language for the UI.
That could likely be changed to use the browser language for everything.
Yes, but I am not sure since when, so I think before the update I’ve used the marketplace binding. Now I’am using the core binding.
And signal is deinstalled and after new install from the marketplace all okay. But I had to think about it, and so my wish of a list only in the log.
Browser language would be useful to set the default language which can then be used on devices which are used by a single user (e.g. a phone) but would be less ideal for tablets on a wall. I imagine a dashboard with pictures/avatars of the members of the home and their home/away status. Pressing on a member switches the dashboard to the configured language for that user.
I like to have support to tag existing rules in textual configuration, such as “Schedule”. Ideally this would be rule “name” (tag=“Schedule”) in the first line.
I’d also like to have “openhab-cli backup” as a buton in the the admin section, resulting in generation of a downloadable zip file in the browser to obtain a quick copy.
That would also be my wish. I once proposed to add this information to metadata itself and then let the UI access the metadata of that item change but the idea to write to the metadata from the UI via a widget was turned down. I we had that we could easily provide a UI and one general rule that would handle that.
is about ephemeris.
only in the log.