Workflow for Translating App Metadata

Also, "changelog" aka "What's New" aka "Recent Changes", which in fdroidclient is shown at the top of the App Details screen if the app is installed. There can be one file per versionCode. See the docs for the file layouts:

https://fdroid.gitlab.io/fdroid-website/docs/All_About_Descriptions_Graphics_and_Screenshots

Repomaker currently does not support changelog and video, but they can be easily added. We should create a new ticket for this though as this is a UX Design ticket.

added Doing and removed ~2112488 labels

tvBanner

@grote What is the tvBanner?

Here's a design to get us started. Comments welcome.

Some very quick feedback:

language should probably be a drop-down list
Offered by is called Author normally
why listing the app versions on that page?
app versions don't normally have icons
app versions can not be reordered by drag and drop
Version, Updated, X ago should not be translated here, this is part of repomaker
why putting the save button in the middle of the page?
should we do auto-save here as in #88 (closed)?

What is the tvBanner?

We can probably ignore this for now, since I am not aware of any app for Android TV. It is like a feature graphic, but used on TVs.

It would be great to also get a design for how users can reach this screen. How they can add new translations and edit existing ones.

It would be great to also get a design for how users can reach this screen. How they can add new translations and edit existing ones.

@grote They would select 'Add Translation' from the language menu.

mentioned in issue #126 (closed)

language should probably be a drop-down list

@grote I made it an input field because I had in mind the use case we heard about in testing, where the user would add a very specific language that wasn't likely to be a streamlined translation language. If we have a dropdown, we could potentially have a very long list to choose from. What if we had an input field that would auto suggest languages from a standard list? Then, if a language is not on the list, they user could just write it in.

Offered by is called Author normally

In the UI, we say 'Developed by'. To make this work for other file types, we should change this wording. I made a ticket #127 (closed)

why listing the app versions on that page?

This is actually showing screenshots displayed differently than before, so that they can easily be re-ordered. Is this something we can get to? If not, we should ignore it.

Version, Updated, X ago should not be translated here, this is part of repomaker

Again, I was thinking about the use case I mentioned above. The simplest solution would be to default to English for these fields if the specified language is not translated in F-Droid.

why putting the save button in the middle of the page?

For large bodies of text, users feel much more comfortable being able to save their changes below the info they added rather than at the top of the page. This is something we uncovered in the user tests. So, I think we should auto-save, but also give the button to save the description as shown. The behavior I imagine is inline with how Gitlab tickets save. You have a button under the text box. Everything on the right hand side (assignee, milestone, labels, etc) save automatically.

should we do auto-save here as in #88 (closed)? Yes.

What if we had an input field that would auto suggest languages from a standard list?

This is a little more tricky to implement (specially since we need to store language codes internally, not names), but probably the best solution. Thanks! I'll see what I can do.

This is actually showing screenshots displayed differently than before, so that they can easily be re-ordered. Is this something we can get to? If not, we should ignore it.

Oh, I thought these are app versions. Reordering screenshots would be an feature of its own. You can create a feature-request for it, if you want.

Version, Updated, X ago should not be translated here, this is part of repomaker

Again, I was thinking about the use case I mentioned above.

Ah I get it now, but then why would somebody want to translate these strings for each app individually?

In my opinion, if somebody wants to use repomaker in a language that is not yet supported, they can go to the translation interface and contribute this translation, the exact same way as it works for the F-Droid app.

So, I think we should auto-save, but also give the button to save the description as shown. The behavior I imagine is inline with how Gitlab tickets save. You have a button under the text box. Everything on the right hand side (assignee, milestone, labels, etc) save automatically.

I am not sure I fully understand. Should we save everything automatically, except the description?

In Gitlab it is more consistent I think, because the comment text is the main part you change and the labels and milestones that get saved automatically or in a side pane that even has a different color. Also there is nothing more below the Comment button in Gitlab, so it is clear that this submits your comment. This reminds me, there also a difference between saving an edit to an existing description and submitting a new comment to a discussion (that obviously can't be submitted before the user considers it ready).

Oh, I thought these are app versions. Reordering screenshots would be an feature of its own. You can create a feature-request for it, if you want.

Ok. I'll file it. But, ignore it for now.

In Gitlab it is more consistent I think, ...

@grote THANK YOU for your feedback! In regards to the description field, I do agree with you. Gitlab is more straight-forward than what the last mockup shows. I think we should auto-save everything. But also, provide a manual way to force save the long text. That's what I'm trying to get at with the design. Because, when people add a large amount of text, it's unsettling to rely on auto-save to save it. It makes users much more comfortable to have control over it.

What if we use a 'submit' button instead, and handle the interactions like this:

I think we should auto-save everything. But also, provide a manual way to force save the long text.

I think the way we would probably implement auto-saving is not by saving every character entered all the time, but only save the changed form content when you leave a form field (it loses focus).

Because, when people add a large amount of text, it's unsettling to rely on auto-save to save it. It makes users much more comfortable to have control over it.

What if we use a 'submit' button instead, and handle the interactions like this:

That can work. Just not sure how the last one with the pen icon fits in now.

We also need to consider the case where a user is editing an existing translated description. How should the submit button look in that case?

Let's assume the user has just entered text and clicks somewhere else. When we auto-save the long description, we should probably show some indication that we are saving. This could be at the top of the page where it also says Changes saved afterwards. But maybe we can also show a small progress spinner inside the submit button, so the user sees right away that things are saved.

I am just a bit worried that this auto-saving and button-saving mix will be confusing for users. And what if the user didn't actually want to save the edited description and changed her mind?

mentioned in issue #130 (closed)

Text and buttons for header about auto saving:

(spinner) Saving changes - x Undo all

Changes saved successfully - x Undo all

Error saving - x Try again

mentioned in issue #153

added localization label

closed

Workflow for Translating App Metadata

Designs

Child items ...

Activity

Admin message

Admin message

Workflow for Translating App Metadata

Activity