@Tlse-vins I agree with the attribute list, it seems good to me.
Now we need to see where in Gladys this could be accommodated. I’m having trouble seeing where we could fit this for now… In fact, I’m even wondering if it makes sense to have this in the product, I don’t see where we could put this without overloading the interface with something that is not necessarily useful on a daily basis:
Maybe this only belongs in the documentation?
Absolutely, we can indicate the list of compatible services in the table.
This, on the other hand, is a more global philosophical question about translations in Gladys. It’s the same problem with the UI: when you develop a feature, you provide translations in which languages?
My opinion is quite clear on this: all languages on which we communicate must be supported, everywhere. I would not accept a PR that does not support the languages on which we communicate, otherwise the UI will be broken everywhere and it makes no sense to say that we manage this language.
You’re talking about German, honestly unless one day we have someone very involved in the project who speaks German and is involved on a daily basis for several months, then yes we will consider German, but otherwise no. Adding a language is very simple, but maintaining a language is a daily job, because translations change several times a day.
This is the philosophy of Gladys 4: we do few things, but what we do we do well.
So don’t worry, there will only be EN and FR to manage.