Jump to content

Wikifunctions talk:Design/About widget improvements

From Wikifunctions
Latest comment: 3 months ago by Amire80 in topic Feedback from Amir E. Aharoni

GrounderUK

This looks like a better approach. I wonder whether it would be possible to give greater visibility to the underlying content when a language is collapsed within the accordion? When there is a label in a given language, it looks as though it will not be obvious that there is no description or if an input lacks a label.

Instead of simply expanding or collapsing the content for a given language, might it be possible for multiple languages to be selected and compared for completeness? If the contributor’s intent is to supply a description (for example) it would be convenient to review descriptions that are available in selected languages.

Another thing we might consider is a feedback mechanism for existing content. For example, it was many weeks before I changed the English label of join two strings (Z10000) to “join two strings”. Whether that is considered an improvement is an open question but most other langages still follow the original label. The situation may be considerably more complex for descriptions, where a useful correction or clarification may occur in any language, with no visibility. (What we need, of course, is abstract content. It would be useful to explore developing that in this restricted domain, but perhaps not in this iteration.)

Will it be possible to edit in two (or more) languages simultaneously? Can the “helper text” langage be selected? GrounderUK (talk) 09:33, 2 July 2024 (UTC)Reply

This looks like a better approach.

thank you! and apologies for the belated reply.

I wonder whether it would be possible to give greater visibility to the underlying content when a language is collapsed within the accordion? When there is a label in a given language, it looks as though it will not be obvious that there is no description or if an input lacks a label.

i’m a bit hesitant to add more information to the collapsed accordion because it defeats the purpose of having a collapsed version, but we could explore a different way to signal that content is missing when the accordion is closed. we filed T370391.

Instead of simply expanding or collapsing the content for a given language, might it be possible for multiple languages to be selected and compared for completeness? If the contributor’s intent is to supply a description (for example) it would be convenient to review descriptions that are available in selected languages.

that’s a great idea. this will probably be addressed once we pick T340624. we haven’t fully fledged this out, but we were thinking about displaying labels in all the languages that a person marked as known languages to them.

Another thing we might consider is a feedback mechanism for existing content. For example, it was many weeks before I changed the English label of join two strings (Z10000) to “join two strings”. Whether that is considered an improvement is an open question but most other langages still follow the original label. The situation may be considerably more complex for descriptions, where a useful correction or clarification may occur in any language, with no visibility. (What we need, of course, is abstract content. It would be useful to explore developing that in this restricted domain, but perhaps not in this iteration.)

opposite to translatewiki.net, wikifunctions doesn’t have (english as) a source language. so, we don’t have a mechanism to prompt editors about recent changes or updates to the “first” label of an object. the (long-term) solution as you suggested could be using abstract content.

Will it be possible to edit in two (or more) languages simultaneously?

yes, you will be able to select and edit as many languages as needed, simultaneously.

Can the “helper text” langage be selected?

not yet. the helper text will follow the mediawiki fallback sequence API. once we pick T340624 we could probably think of making the language of the helper text customizable. AAlhazwani (WMF) (talk) 08:29, 18 July 2024 (UTC)Reply
Thank you for your reply. With regard to feedback mechanisms, I appreciate that there are technical challenges but there are two things we might consider.
The first is a more granular Watchlist, so that a user can watch content changes for specific languages. Some users will be interested in any content anywhere in a list of languages. Others will be interested in changes to an object that are not multilingual, or only those that are in a language with which they are familiar. Given this capability, watching a page could (by default) watch the multilingual content that is currently exposed in the accordion, which would typically include any new content and the existing content that was referred to when creating the new content. I think we shall need this improved granularity for Abstract Wikipedia, but there it will be quite a bit more complex.
The second is an option to register a degree of doubt about some content. We could adopt some conventions in the content itself, but some kind of reaction feature might be possible. If so, it could also be used to indicate that the content has been translated into or from a particular language (which is something we would not generally want to see in the content itself). GrounderUK (talk) 10:56, 18 July 2024 (UTC)Reply

box sizes in quick edit mode

I would like larger box sizes in the quick edit mode. I often interact with functions where the label and short description are near their respective character limits, and it is annoying to have to scroll in the edit boxes.

When not in quick edit mode, when inputs are given a two or three word name, they get line-breaks from wrapping. I wonder if they should get a whole line to themselves (left-justified), then their type would have the next line to itself (right justified)? 99of9 (talk) 23:29, 16 October 2024 (UTC)Reply

Feedback from Amir E. Aharoni

To @Sannita (WMF)'s question on Wikifunctions:Project chat:

What do you think of our improvements of the user interface? Is it functional?

I don't remember the old one, so I don't know if it's an improvement. The current one kind of works: I am able to make some edits, but I don't feel entirely comfortable or confident.

Does it help you doing your work?

I am mostly doing translations of labels for now, and it's not great. On Wikidata, after I write (or translate, which is more or less the same thing) a label, a description, or a value, I don't have to write an edit summary. Unlike it is on Wikipedia, an edit summary is almost never needed on Wikidata or Wikifunctions. But here, after I press Publish, I have to write an edit summary, and it appears here as a separate dialog, like in Wikipedia's Visual Editor. This is annoying, especially when I translate the labels if several things that I open in several tabs.

I'd understand the need for an edit summary in more significant things like editing the code of an implementation, but for simply translating a label, it's almost never necessary.

Is there anything we should fix or improve?

What would help me is to consistently see the labels and the descriptions in some other languages, for example those in my Babel box, as it is on Wikidata. Currently, I don't see them, even though they exist. I can see them all by clicking the "X languages" box, but I want to see at least some of them immediately. That's how all the computer-aided translation interfaces that I know work.

What do you think of the workflow to edit multiple language labels in one edit? Does it work? Is it simple? Is there anything we should fix or improve?

Dynamically adding more languages to the About box in editing mode by clicking the "X languages" box and then clicking the language is weird. I wouldn't even know that it exists if you didn't ask about it.

Most of the time it's not necessarily at all, at least to me, because I usually write them in one language, and I suspect that the same is true for most people: they want to see existing labels, descriptions, and aliases in one other language they can write (often, but not necessarily, English), and to translate to one other language they can write.

Reading in more than one language and translating into more than one language is useful, but only occasionally, and I'm not sure that the current interface would be convenient for such cases.

Does the language fallback strategy we implemented work? Have you had need to try it? Is it functional? Is there anything we should fix or improve?

I don't think it works. I couldn't understand or see it at all.

A couple of additions for the end:

  1. In addition to what I wrote here, I also reported a few bugs on Phabricator.
  2. It's hard to write about it like this. I feel that it would be much more useful and efficient for me and for you to have a live conversation about it with a design researcher. I'm happy to do it if anyone is interested.

Amir E. Aharoni (talk) 03:39, 19 October 2024 (UTC)Reply