Hello again, i18n list!
Today I'm here to bug you about a new extension, BetaFeatures[0]. It's been high priority for me for the past few weeks, and it's coming to fruition very quickly. Quim and I were just chatting about translating it, though, and one of the strings (which is a description of a feature[1]) is very long, longer than one might expect for a translator to follow.
I'm wondering what the possible solutions are, for this. There will be multiple features registered in the weeks to come, and it will be other projects registering the features, not BetaFeatures itself. The messages will likely be created in other repositories. So I'll need a recommendation for those developers to avoid irritating translatewiki.
Your help here is very much appreciated - we're looking to get this extension out and deployed in the very near future, so it would be great to push a new way to translate these longer messages very soon.
[0] http://www.mediawiki.org/wiki/Extension:BetaFeatures [1] http://multimedia-alpha.wmflabs.org/wiki/MediaWiki:Betafeatures-auto-enroll-...
Hi Mark, do not worry, it's not too long. We translate much longer messages all the time.
Purodha
Von: "Mark Holmquist" mtraceur@member.fsf.org
Hello again, i18n list!
Today I'm here to bug you about a new extension, BetaFeatures[0]. It's been high priority for me for the past few weeks, and it's coming to fruition very quickly. Quim and I were just chatting about translating it, though, and one of the strings (which is a description of a feature[1]) is very long, longer than one might expect for a translator to follow.
I'm wondering what the possible solutions are, for this. There will be multiple features registered in the weeks to come, and it will be other projects registering the features, not BetaFeatures itself. The messages will likely be created in other repositories. So I'll need a recommendation for those developers to avoid irritating translatewiki.
Your help here is very much appreciated - we're looking to get this extension out and deployed in the very near future, so it would be great to push a new way to translate these longer messages very soon.
[0] http://www.mediawiki.org/wiki/Extension:BetaFeatures [1] http://multimedia-alpha.wmflabs.org/wiki/MediaWiki:Betafeatures-auto-enroll-...]
-- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur@member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist%5Bhttps://wikimediafoun...]
Hey Mark,
On Wed, Sep 4, 2013 at 6:59 PM, Mark Holmquist mtraceur@member.fsf.orgwrote:
Hello again, i18n list!
Thanks for sending the mail. Hello to you, too ;).
Today I'm here to bug you about a new extension, BetaFeatures[0].
Best thing since sliced bread!
It's been high priority for me for the past few weeks, and it's coming to fruition very quickly. Quim and I were just chatting about translating it, though, and one of the strings (which is a description of a feature[1]) is very long, longer than one might expect for a translator to follow.
If you re-read this sentence, I think you may notice what's wrong, and what needs to be fixed. Ignore and read on for less of a puzzle :).
I'm wondering what the possible solutions are, for this. There will be multiple features registered in the weeks to come, and it will be other projects registering the features, not BetaFeatures itself. The messages will likely be created in other repositories. So I'll need a recommendation for those developers to avoid irritating translatewiki.
If there is a need to use a lot of text, a lot of text should be used. In case of the beta features, I think we should consider taking a hybrid approach. Make it as brief, international English and concise as possible descriptions of features. Give the features a title, as those are used to easily refer to the features (Flow, Notifications, ULS, Content translation, ...). Gadgets descriptions[2] are a good example, I think.
If you think you need the following amount of text to describe a feature:
This is for the daring, intrepid early adopters who want to see every single experimental feature as it rolls out. Your account will automatically get the latest features when they come out. You can always come back to this page to disable the ones you decide not to use, but this will give you the most bleeding-edge experience on the site. ... consider thinking some more. Does this say about the same, and conveys the same concept requiring less time of the user?
[checkbox] Automatically use all experimental features.
Some explanation: - Sentence 1 and 2 appear to be slightly redundant and unnecessarily wordy. - Sentence 3 is. IMO, a superfluous explanation of what a checkbox can do. It would be overkill to add this to each and every feature description. If you find it's really important for users to point out that a preference that was enabled on this location, can also be disabled here, consider adding it in the header of the special page, as the tip goes for all the feature descriptions.
Your help here is very much appreciated - we're looking to get this extension out and deployed in the very near future, so it would be great to push a new way to translate these longer messages very soon.
Short strings are skipped less often than longer strings. Users don't read. Two important reasons to keep things brief and clear.
[0] http://www.mediawiki.org/wiki/Extension:BetaFeatures [1] http://multimedia-alpha.wmflabs.org/wiki/MediaWiki:Betafeatures-auto-enroll-...
[2] https://meta.wikimedia.org/wiki/Special:Preferences?uselang=en#mw-prefsectio...
On Wed, Sep 04, 2013 at 07:59:53PM +0200, Siebrand Mazeland (WMF) wrote:
This is for the daring, intrepid early adopters who want to see every single experimental feature as it rolls out. Your account will automatically get the latest features when they come out. You can always come back to this page to disable the ones you decide not to use, but this will give you the most bleeding-edge experience on the site.
... consider thinking some more. Does this say about the same, and conveys the same concept requiring less time of the user?
[checkbox] Automatically use all experimental features.
This was your suggestion on the patchset, when it first surfaced, IIRC. But I'm not sure that the explanations are both the same - your suggestion gives the impression that the user would have every feature enabled by this one, which isn't the case. *Future* features will all be enabled by default, but existing ones will stay disabled if they were before.
In any case, I feel I may not have been terribly clear - I *want* there to be long-form descriptions of these features. People are working on them and want to "sell" them to users, and this is their chance. We have, comparatively to old preference fields, a much larger amount of space to use for descriptions of features, which (I believe) is part of what the design team intended - see this screenshot[0] of the extension's tab, for example.
I'll get in touch with them to see if I can push back on that part of it, but if we end up with longer descriptions, what would your suggestion be?
[0] https://commons.wikimedia.org/wiki/File:BetaFeatures_2013-09-04.png
On Wed, Sep 4, 2013 at 8:34 PM, Mark Holmquist mtraceur@member.fsf.orgwrote:
On Wed, Sep 04, 2013 at 07:59:53PM +0200, Siebrand Mazeland (WMF) wrote:
This is for the daring, intrepid early adopters who want to see every single experimental feature as it rolls out. Your account will automatically get the latest features when they come out. You can always come back to this page to disable the ones you decide not to use, but
this
will give you the most bleeding-edge experience on the site.
... consider thinking some more. Does this say about the same, and
conveys
the same concept requiring less time of the user?
[checkbox] Automatically use all experimental features.
This was your suggestion on the patchset, when it first surfaced, IIRC.
At least I'm consistent :).
But I'm not sure that the explanations are both the same - your suggestion gives the impression that the user would have every feature enabled by this one, which isn't the case. *Future* features will all be enabled by default, but existing ones will stay disabled if they were before.
In any case, I feel I may not have been terribly clear - I *want* there to be long-form descriptions of these features. People are working on them and want to "sell" them to users, and this is their chance. We have, comparatively to old preference fields, a much larger amount of space to use for descriptions of features, which (I believe) is part of what the design team intended - see this screenshot[0] of the extension's tab, for example.
I'll get in touch with them to see if I can push back on that part of it, but if we end up with longer descriptions, what would your suggestion be?
International English, well thought out, as brief as possible. People don't read. Really, they don't[1].
The screenshot is very useful. The 4-6 word heading will probably do the trick. Make that suck less, and the fine print will be ir^H^Hless relevant.
[0] https://commons.wikimedia.org/wiki/File:BetaFeatures_2013-09-04.png
[1] http://uxmyths.com/post/647473628/myth-people-read-on-the-web
-- Mark Holmquist
Siebrand
On Wed, Sep 4, 2013 at 11:44 AM, Siebrand Mazeland (WMF) < smazeland@wikimedia.org> wrote:
On Wed, Sep 4, 2013 at 8:34 PM, Mark Holmquist mtraceur@member.fsf.orgwrote:
I *want* there
to be long-form descriptions of these features. People are working on
them and want to "sell" them to users, and this is their chance. ...
... People don't read. Really, they don't[1].
Indeed, except when you do want to know more. So offer more info: in a tooltip, a link to more info, or an "expanded explanation".
The create account form tells you to enter a username, and some people (who really want the username "Foo@☺ Admin") need a longer explanation. E3 tried a tipsy pop-up but I think a label that expands to provide more info would be a useful gadget in both places.
Indeed, except when you do want to know more. So offer more info: in a tooltip, a link to more info, or an "expanded explanation".
Another factor to consider about the length of descriptions is whether you are displaying a list of items or a detailed view of one of them. In a list, the overload of text multiplies per the number of elements making it harder to scan.
App stores and browser extension repositories, show very little information when displaying a list of apps/add-ons (icon, category, user feedback/users, and some include a short description). Detail pages have longer descriptions (although screenshots galleries are normally more prominent than descriptions in that context).
Longer descriptions at detail pages are not that problematic in comparison, but even there the more concise and clear the information the better. If users know that there are no problematic side-effects by adding/removing a feature (the platform should convey that), users will be encouraged to explore and try them.
Pau
On Wed, Sep 4, 2013 at 9:39 PM, S Page spage@wikimedia.org wrote:
On Wed, Sep 4, 2013 at 11:44 AM, Siebrand Mazeland (WMF) < smazeland@wikimedia.org> wrote:
On Wed, Sep 4, 2013 at 8:34 PM, Mark Holmquist mtraceur@member.fsf.orgwrote:
I *want* there
to be long-form descriptions of these features. People are working on
them and want to "sell" them to users, and this is their chance. ...
... People don't read. Really, they don't[1].
Indeed, except when you do want to know more. So offer more info: in a tooltip, a link to more info, or an "expanded explanation".
The create account form tells you to enter a username, and some people (who really want the username "Foo@☺ Admin") need a longer explanation. E3 tried a tipsy pop-up but I think a label that expands to provide more info would be a useful gadget in both places.
-- =S Page
Mediawiki-i18n mailing list Mediawiki-i18n@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
mediawiki-i18n@lists.wikimedia.org