integreat-app
integreat-app copied to clipboard
digitalfabrik
More information when translation is not available for certain languages
As a user I want to know why I cant select my language. If a translation is not available, we should therefore show a message on touch of a language.
Acceptance criteria:
- If a language is not available, touching it will show the same message as on hover in web ("This language is not available")
- Not available languages are still greyed out
- Nothing changes for available languages
Old description:
I have received this feedback from the project "Digital Active Women": They have emphasized that they notice when a page is available in German but not in their own language. It makes them feel as if others would decide what is relevant to them and what they can or can not know.
We could change this for example by including a short information text, when no translation is available such as:
"Sorry. This page does not exist in your language as it has not been translated yet. Click here to read the [German/English] page."
@clarabracklo as long as the title is translated, that functionality already exists. Maybe it is something we need to make municipalities aware of - otherwise we can maybe implement some functionality that allows translation of the title only. Not sure if that is feasible. Here you can see what it would look like: https://integreat.app/testumgebung/en/social-life
Also, I am taking this feedback into the Dialogforum tmr :) advising municipalities to explain why certain languages are available and others not (app wide and also per page) and remind them about the Platzhalter-function
@osmers As far as I understood an explanation of WHY it is not available would be appreciated but I am happy that this is already making its way to the Dialogforum :)
Maybe we can ammend the text displayed in the app to include the explanation that it has not yet been translated but will be in the (near) future. :)
You mean this text should be adjusted to show that it has not been translated yet?
We should also think about native bc we don't show any information there yet. Perhaps a snackbar makes sense.
@clarabracklo as long as the title is translated, that functionality already exists. Maybe it is something we need to make municipalities aware of - otherwise we can maybe implement some functionality that allows translation of the title only. Not sure if that is feasible. Here you can see what it would look like: https://integreat.app/testumgebung/en/social-life
If its more about showing text like this I would say this is more of an CMS issue.
@steffenkleinle Maybe just changing the text to "Noch keine Übersetzung verfügbar" if possible (and not too long) and still moving the task to CMS for the possibility of further adjustments?
You mean this text should be adjusted to show that it has not been translated yet?
We should also think about native bc we don't show any information there yet. Perhaps a snackbar makes sense.
That would also be an option, I think - definitely does not hurt to have it mentioned in both places, but I meant to change the text that is currently shown inside the content bcs it is already really close to what Clara suggested :) and yes, I think I remember that the placeholder is supplied by the CMS team... @clarabracklo do you want to open an issue in the CMS GitHub?
Edit: Just saw Claras comment - the tiny problem we have here is that for some topics (e.g. Ukraine) municipalities chose not to translate it to say, Arabic - so there will never be a translation and "noch" can be misleading
I would suggest leaving it to the municipalities to decide which pages they want to translate - the Co-Forscherinnen also suggested adding a page where such decisions are explained. That is something the municipalities can do as well.
We can quite easily adjust the text in the message that is displayed on hovering/clicking, yes.
However, that text is only displayed if the CMS tells us that a language is not available. This is not the case in the linked example (https://integreat.app/testumgebung/en/social-life), i.e. english is still shown as an available language on the german page (https://integreat.app/testumgebung/de/gesellschaftliches-leben/). That would be a CMS issue but I am not sure how easily it would be feasible to change that.
Regarding changing it to "NOCH keine Übersetzung verfügbar": That is quite easy, you should just agree on it.
In the end the goal should be that users do not feel patronized by the content creators (municipalities) too much and feel as much as possible free to find all information they want. I am sure there are several ways of achieving this (page in Integreat, different text displayed, really emphasizing how important it is to translate everything etc.) I am not sure what the best first step would be. Maybe @dkehne and @osmers can discuss and make a decision about this as product owners of Integreat?
We can quite easily adjust the text in the message that is displayed on hovering/clicking, yes.
However, that text is only displayed if the CMS tells us that a language is not available. This is not the case in the linked example (https://integreat.app/testumgebung/en/social-life), i.e. english is still shown as an available language on the german page (https://integreat.app/testumgebung/de/gesellschaftliches-leben/). That would be a CMS issue but I am not sure how easily it would be feasible to change that.
It is not really intended to change that bcs it's excatly the functionality we want. It is specifically for pages, where the municipalities are planning a translation but have not gotten around to it yet. This way users know that the content exists, and can choose which language they want. Especially important if they are already navigating in that language. Otherwise they would never know this content existed unless they changed to a language that has the content.
The only thing I would change is that the native app also shows the information "no translation available" - I would not change it to "noch keine Übersetzung verfügbar" because not all pages will be translated necessarily. And where translation is planned, a Platzhalter can be used. But I will take it with me for the next Service Call :)
@clarabracklo does that work for you or do you think something else should be done?
From @osmers comment I would at the moment see the only task of adding a hint for the native app that a translation/language is not available (e.g. with a snackbar).
@steffenkleinle I am supporting any decision from @osmers here :) Just wanted to forward the feedback! So yes, it works for m :)
We discussed this and would like to keep the wording as it is and only add the message to native, as @steffenkleinle said :)
@hauf-toni we should think about a good concept how to display this "translation not available" information for mobile.
@sarahsporck @clarabracklo @steffenkleinle Is there any (technical or other) reason, why we still show languages as disabled state even though there is no translation? How about just displaying available languages. If no translations for a specific language is available, the language should not being displayed (also not in a disabled state).
@sarahsporck @clarabracklo @steffenkleinle Is there any (technical or other) reason, why we still show languages as disabled state even though there is no translation? How about just displaying available languages. If no translations for a specific language is available, the language should not being displayed (also not in a disabled state).
We thought that this UX makes sense as the alternative is worse in our opinion. Only conditionally displaying the languages leads to
- Varying sizes of the language selection modal
- Different positions of the same language depending on other languages
- Confusion why the users language disappeared all of a sudden
- No explanation possible
If you say that it is better to not show unavailable languages, we can do so. There is no technical reason for it.
From the UX pov, I would suggest to just display the available languages. There are 2 UX rules that I would follow here. Hick's law "The time it takes to make a decision increases with the number of choices available. In UX design, this law reminds us to keep things simple and limit the number of options presented to users." Jacob's Law Users spend most of their time on other websites, so they expect your website to work just like all the other websites they already know. In UX design, this law reminds us to follow established design patterns and conventions to make our websites more intuitive and user-friendly. --> in other websites, you only can select languages which are really available.
This way, this would also be consistent in web and app. @osmers Would this solution approach would solve the problem also?
@dkehne since this is an app issue, maybe you have an opinion or input - especially on whether to keep inactive/not available languages or not. I am in favor of keeping them (with the added message on why they might not be available) plus, I think pretty soon most translations will be available, so maybe we shouldn't put too much work into this?
This way, this would also be consistent in web and app. @osmers Would this solution approach would solve the problem also?
@IsabellaTG what do you mean by consistent in app and web? Currently we are consistent, right? Showing all languages always in the selection.
I wouldn't put in the "why" but as I may interpret Clara's words tapping a greyed out language from the language selection should trigger some notification that it is not available.
Users who are not familiar with the construct of greyed-out labels should be supported more in understanding that the translation is not existing at the moment.
With our machine translation approach there is no good answer why a translation in an already existing language is not supported anymore....
This way, this would also be consistent in web and app. @osmers Would this solution approach would solve the problem also?
@IsabellaTG what do you mean by consistent in app and web? Currently we are consistent, right? Showing all languages always in the selection.
Yes it is consistent in the current solution (disabled language). The inconsistency relates to the solution approach on displaying the "why" information in web as tooltip and as snackbar on mobile. The difference is on the usage definitions of the components and on the users interaction as tooltips on the web can be activated by hover. Snackbars, however, usually require a touch or click to show the information. If tooltips are used on the web, it could be confusing if the mobile app uses snackbars instead. This can affect the user experience, especially if the user accidentally closes the snackbar or disappears too quickly.
Maybe we should just remove the explanation then so that it is the same experience on web and native or add on both projects some kind of "Keine Übersetzung verfügbar" to explain at least what the grey non-clickable button means?
We cannot deliver an explination of the why.