The main purpose of the Translate Interface Update page is
1. To check the status of the updates
2. To decide whether or not to update the translations manually
The page is mainly used by:
a. System administrators
b. Translation maintainers
I have reworked the design of the page to simplify it, to remove noise and modeled it after the Available Updates page. See http://drupal.org/files/l10n_update-simplity-update-page.png
Notes in the design:
1. Click to expand/collapse. Collapsed by default.
2. Shows 'Up to date' when all of this module are up to date. Shows 'Updates available' when one or more updates are available.
3. No local/remote text.
4. Summary status is only shown when collapsed.
5. Link to ftp.drupal.org

Parent issues (for Drupal 8 inclusion)

#1191488: META: Integrate l10n_update functionality in core
#1260690: META: Improve multilingual user experience in Drupal 8

Comments

hansfn’s picture

Looks much better. If this is implemented, you can of course closed my bug report #1025562: List of updated translation contains duplicate/wrong statuses. Maybe mark my bug as duplicate?

Gábor Hojtsy’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev

I agree it would very well do with some simplification, and I think Jose wrote that in email as well. Moving to 7.x, let's implement it there first and then move back to D6. Would be good to get some feedback.

Sutharsan’s picture

Issue tags: +Needs usability review
BrightBold’s picture

I was just struggling with the styling on this page, so I really like the suggested format. (note: the first link to the PNG in your original post is broken — you're missing "issues/" in the path.)

As a favor to themers, it would be great if, as part of this project you added an ID to the table so that we could theme this page separately from the Available Update page, since both share the .update class but then offer different output, so styles that work on Available Updates don't necessarily translate well to Translation Updates.

I've attached a screenshot of the default appearence in Bartik, which (as I'm sure you've noticed) offers some room for improvement! Happy to help test / contribute CSS / etc.

Gábor Hojtsy’s picture

Yes, I think we all agree this page seriously needs improvement, and the maintainer is on board as well :)

Sutharsan’s picture

Collapsed fieldset 'Languages' is not noticed by first users. See #1042168: Bugs detected and locale's support needed

Sutharsan’s picture

Assigned: Unassigned » Sutharsan
xpound’s picture

Sugestion: Put configs at top of the page and turn collapsible off for all this fields [no need].

Sutharsan’s picture

Status: Active » Needs review
FileSize
42.03 KB
9.32 KB

This first version is functional but still rough. Test it and give your feedback.

Gábor Hojtsy’s picture

The screenshot visually looks great. Did not have time to look into the code yet.

Sutharsan’s picture

The patch is functional code. But it needs clean-up, class/variable naming, js namespace, css tuning, etc. I like to get if functionally fixed first before I do the tuning.

klonos’s picture

I understand the logic behind having the module's page as a tab under regional settings, but one might also expect it to be under the site's "Available updates" page either as a separate "Translations updates" tab, or merged in the available module/theme updates table.

Gábor Hojtsy’s picture

Yeah, it sounds like it would make sense both ways. Would it hurt to have it at both places? Should not require a big code change I'd think.

Sutharsan’s picture

After too long delay, here is a fully working version of the initial idea.

Unfortunately I had to add images to the module which duplicate the collapsed/expanded triangles of the menu module. Re-using the css class of menu of fieldset was not possible (because they use 'ul li' or 'fieldset') nor using the way the Simpletest module includes the triangles.

I did not consider klonos suggestion (yet). This can be discussed separately.

Sutharsan’s picture

And an image for a quick impression

Gábor Hojtsy’s picture

Looks pretty good visually (have not checked the code).

Sutharsan’s picture

xpound’s picture

Make it available for D6! :P

Sutharsan’s picture

Status: Needs review » Fixed

Committed to 7.x-1.x.

Sutharsan’s picture

Status: Fixed » Patch (to be ported)

Now to be ported to 6.x.

Sutharsan’s picture

Assigned: Sutharsan » Unassigned
Sutharsan’s picture

Assigned: Unassigned » Sutharsan
Status: Patch (to be ported) » Needs work
FileSize
4.44 KB

I worked on the interface with betarobot last weekend at Drupal Design Camp. The attached patch and screenshots are of a working version, but it needs more work:
* Design/UX review
* Evaluate the update status indication (text, icon, color) of both projects and languages per project
* Check if we still benefit from re-using the Local module style sheet or if we are more busy overriding it.

Sutharsan’s picture

And a screenshot...

Gábor Hojtsy’s picture

Looks pretty good. I especially like how it prints the server used when it tells you the file was not available.

Sutharsan’s picture

The server is printed here because it is a non-standard server. I understand your confusion, but I added this to the devel.info for test. For not being able to connect to the server we can use an error message just like Update module does and include the server name + link in it.

Bojhan’s picture

subscribe

Sutharsan’s picture

I find myself sometimes confused by the project and/or language states or status messages. Therefore I wanted to define the meaning of a states from a user point of view.

General status

Error
Failed to get data of available updates.
  • Remote translation source: Can't reach the server.
  • Local translation source: No po file available.

Project status

Unknown
No update available or Avaiability of updates can not be determined.
Remote translation source:
  • Can not reach the server.
  • No release available (dev-release, new module, custom module).

Local translation source:

  • No file available.

One or more languages in this project have this state.

Warning
Updates available for one or more languages in this project (Language status = Warning).
Ok
All languages of this project are up to date (Language status = Ok)

Language status

Unknown
Never upated or unable to determine the status.
Warning
Translation is outdated (based on module version or date).
Ok
Translation is up to date (based on module version or date)
Bojhan’s picture

FileSize
71.57 KB

Since this is up for Drupal core inclusion, I have done my first try at simplifying this screen. One of the major changes I have made is removed anything that is OK. The reason that I did this, beside that it creates a whole lot more clarity - is that people should come to this page to take action. For fully informing them about each individual translation they have on the system, we should have a report page.

I have made a few assumptions to make this easier to use. One of them is that the user wants to use the web installer, to update the translations - it's likely we want a global on/off switch for this. Additionally I have disallowed the individual installation of translations, for example updating french but not dutch for Views 7.3 - because to me this seems a edge case that could be solved with a contrib.

translationupdate.jpg

I have elevated Drupal core from the list, as I believe this to be the most important thing on the page and the most common use case for updating a UI translation.

This is quite a different way for core, and a major consideration I have yet to make is how we make this kind of updating more consistent across the board (all updates, translations, modules, themes, core).

I have taken over sutha's idea of using harmonica pattern that is used in the FieldUI too, when a user clicks on Details it shows which language updates will be installed.

Gábor Hojtsy’s picture

I think this looks pretty good. For translations, we do have updates for existing versions as well though. So current might be 7.3, while recommended is 7.3 (but a later version of it), that is why l10n_update maintains the original datestamp of files and presents the new datestamp as well. We don't have distinct version numbers for translation files, but use the original module version number and regenerate the file with new data on later dates when new translations are entered.

Gábor Hojtsy’s picture

Also I do agree this complicates updating both core and contrib at once.

Bojhan’s picture

We could definitely add dates next to the version numbers.

Bojhan’s picture

Gábor Hojtsy’s picture

Issue tags: +D8MI

Tagging for D8MI.

arunaseva’s picture

I installed a language (import .po file):

http://img21.imageshack.us/img21/6999/35846128.png

But no update information (update available or up to date) for the language:

http://img695.imageshack.us/img695/8252/14206457.png

Is it a bug? (I tried to check the interface)
I used dev versions.

yannisc’s picture

Having installed the dev version just now, it looks much prettier and it's more usable than beta2.

I only had 2 minor problems usability-wise:

1. I hesitated to click on the module name to expand, thinking that maybe that click would take me out of the status page, to the module page.

2. Languages option to select which languages to update was not apparent at all. I had to be in the code sprint and "check what's wrong" to be able to see it (confirming comment #6). I suggest having this fieldset expanded.

Sutharsan’s picture

@halinux, this is a different issue. I remember this faulty behavior and have been working on it. Pls check the issue queue or create a new issue.

Sutharsan’s picture

Project: Localization update » Drupal core
Issue summary: View changes

Add parent issue

podarok’s picture

Project: Drupal core » Localization update

subscribe

dboulet’s picture

Subscribe.

Gábor Hojtsy’s picture

Issue tags: +montreal

Discussed a lot at the Montreal sprint. Feedback coming up.

Jose Reyero’s picture

Thinking again about this page -and I agree all the screenshots here look way better than the original- I think we are missing the point somehow.

The page was inspired, as it's obvious by the module update page. This was the original mistake.

Why do we need all the module / version information in the first place? Why not group it by language instead of by module?

In thinking a few simple, simple rows like:
-------------------------------------------------------
- Spanish - 3 modules can be updated [Small update button]
- German - 4 modules can be updated [Small update button]
- French - No updates available

Just a big button: [Update All]

And that should be it. Anyway, if you want to work a bit more you can add the modules/versions in a (collapsed) fieldset below the language, etc...

Anyway, has anyone ever used it for something different than downloading all pending updates?

Gábor Hojtsy’s picture

FileSize
144.95 KB

So as said, we discussed this a lot here in Montreal. Here is some feedback we had:

  • We assume most people on small sites will just go with automatic updates. We should make those simpler to configure (but possibly not enable out of the box, well). So those people will not have much use for this screen, it will just happen on their site automatically.
  • For those, who actually use this screen, those are the perfectionists, tinkerers and QA people. For them, the real question is "What the hell actually changed in those files". Obviously we cannot tell that before we downloaded all the files and looked at them, but that is really the info they are looking to get here, right? However we slice and dice the numbers we have, that is not really the important info for the type of person looking at this screen. All they want is "what is new" and "what is changed". For that, we actually discussed a "Preview changes" button, that would (a) download all the translation files but (b) DO NOT IMPORT them. Instead it would compare the data in the files to the database and just make note of all the differences. We already have kind of this code, we just need to skip the overwriting/entering of the data at the end. Then we can show a summary report of what we gathered and then have a "Continue with import" button at the end that actually does the import. I realize this is like a huge new feature for the module, while all of what we were supposed to do is simplify this page, but it came out of our assessment of what this page is really for. And that was it.
  • Finally, for the selection itself, we figured out using a collapsed, expandable set of checkboxes UI like the simpletest module does makes sense, where you have a big global checkbox and then have sets of checkboxes that are "locally global" to the lists under them. We could basically reuse the same concept here to let users refine their selections to however refined they want it to be, but initially just show them collapsed, like simpletest's UI does, so the optional details are hidden. I'm not 100% the hierarchy is that visible here, but it is the pattern we have so far for this kind of drill-down UI.

Once again, this is feedback from our group discussion of about 4-5 people looking at this screen for about an hour or so.

Jose Reyero’s picture

Great ideas in #41, I think these could be merged with #40 too. I still think this should be organized by languages.

The preview option sounds really cool but I think for simple importing of po files too so maybe it should be a more generic feature. As the current page mixes both, downloading and importing and also some options for importing, we could do some further break down and reordering.

The import options we have for this page are:
- Import and override existing translations.
- Import but don't override translations.
To these we could add:
- Preview

Also if we have on this page the 'Just download' option, we could move the import/preview operation to current locale import page so it provides the option to import any already downloaded but not imported file, or upload a new one. The picky people can just go importing module by module.

So we should consider some serious merging of this translation update page with the locale import po page.

Gábor Hojtsy’s picture

@Jose: yes I fully agree the locale import page and this mass download/import page should not co-exist as separate items really, if we can find any good way to merge them :)

Gábor Hojtsy’s picture

@omar submitted two sub-issues for this: #1280516: Make selections options behave like those on testing page and #1280504: Add "preview changes" button. I think maybe we can make the first one duplicate of this one, if we do agree that looks like a good direction to go? I mean if we have that issue, this one does not make much sense anymore, but here is all our discussions :)

Bojhan’s picture

Automatic updates is there an issue on this?

Also the simpletest interface is not very good. We need to figure out a consistent pattern for collapsing items inside a table. I am not really sure where any of the information about the language you are updating too goes? Also why do you group modules? Isn't it more often that not that an individual module receives an update or change?

The feature of checking what are the actual changes version to version, seems like a bit extreme use case for core to handle? It instantly makes it far more difficult, creating two options of updating. Additionally this needs a lot of maintenance for this feature to be useable.

Similar to the other issues on internationalization, rather than improving the UX we are making simple proposals more complex adding things like "locale import po page functionality", "preview" and "grouping per group of modules". This is a bad trend, we need to consider what is essential to communicate - and not assume that its "experts" that will be on this page (I dont think we should optimize these kind of screens in core for experts - that is what contrib is for).

Lets get some feedback going on the existing mockups, and move from there. I feel like this needs more exploration and possibly a summary of what the important information is and what a common data usecase would be.

Gábor Hojtsy’s picture

@Bojhan: well, this whole screen targets experts, so if we don't want it in core eventually, we can keep this in the contrib l10n_update module. Those who are not experts will clearly just use the automated cron download and update option or want ONE button that says ("Update all stuff for me NOW"). This whole overview of date information and up-to-dateness is really scary for anyone but experts IMHO and should be targeted there with useful bits instead of fancy numbers they cannot do much with, right?

Bojhan’s picture

I am a bit confused, I do not see how this is for experts. Any site that doesn't use automatic updates, isn't necessarily an expert? I thought any change or custom module that one makes will mean making use of this list. Perhaps I need to know more about this automatic update thing, is it documented anywhere?

Sutharsan’s picture

@Bojhan, The README.txt describes the current functions of the module. Perhaps that helps.

I am a worried about the wish to select individual string updates. On a fairly random translation update I just executed, 9 modules where update with a total of 430 updated strings. Is this manageable? Will language maintainers go through hundreds of strings before they accept an update? I like to know this from real users and real use cases. If this gets in at all, it should be in contrib and not in core.

Gábor Hojtsy’s picture

@Sutharsan, @Bojhan: yeah, well, our observation here at the Montreal sprint was that instead of trying to reorganize the information on the page, we should figure out (a) why would we go to this page anyway and then (b) what functionality do we want from it. What do you want to know from this page? Is it interesting that 3 new translation files are available? Would you do something else on this page if that number is 1 or 8? How do those numbers help you in deciding what to do here? What do you really want to get out of this page?

Bojhan’s picture

Can you answer those questions yourself? Seems weird to ask me

Gábor Hojtsy’s picture

@Bojhan: my answer to that is that file level counter info does not inform me of anything. If there were 8 files changed for Hungarian and 1 file for Spanish, those 8 files might still change only 10 strings, while the 1 Spanish file might change hundreds. There is no way for me to review the effect of what I'm going to do here, it just tells me which languages and modules are affected (which is useful for checking up later after the fact), but how many files are changed is not really useful at all. For checking up later after the fact, most module UIs are so extensive that checking whether there are bad changes in the updates is pretty impossible and a huge time waste.

I don't think it makes sense much to selectively update translations here, since it just makes more work for me to manually try to find what changed where multiple times. I personally would prefer to do it at once because then I only need to review at once. So the level of detail is not enough to rule out certain updates so since it does not make me deselect any update from the whole list anyway, I consider this level of detail of not much use for me. That is my feedback, but obviously looking for more.

Jose Reyero’s picture

I agree with @Bojhan in #45 about selecting individual strings being an extreme use case, and also being too complex feature, it should be in contrib.

Actually for people wanting to review strings one at a time, they should be running their own localization server, and there they have all the tools.

So we should really go for simple simple stuff into Drupal core and I believe the simplest still useful one is just grouping and allowing updates per Language. Let me explain:
On a mid size multilingual site operation, you have translators for languages. Thus it is each language translator who may be responsible for updating their strings, just for that language, then maybe review them after updating, etc.. This is why I think the only grouping that makes sense is per language. Having modules and releases there will just confuse people more.

Also I think the module upgrade page should provide an option (simple checkbox) to upgrade your translations along with your modules.

Gábor Hojtsy’s picture

@Jose: yes, that is exactly the kind of feedback we need here :) Others agree, disagree?

Sutharsan’s picture

Agree with the option to update per language.

When talking about manual or automatic update I can think of three options:
1. Automatic: update when module is enabled, update when language is added, update when module is updated, update all on cron.
2. Install/update only: No. 1, but without cron.
3. Manual: No automated actions.

Automatic update should be the default. I expect 'Automatic' to be used during site construction and 'Manual' during production.

I consider No. 2 as optional for core, it may be too advanced. It is a replacement of the D6 situation where modules were shipped with their own translation files. But I have no clear use case for this option.

Manual update: Update translations of all enabled modules for every selected language.

Bojhan’s picture

Can we decide to either move on or postpone this for core?

Gábor Hojtsy’s picture

@Bojhan: It is certainly not currently applicable to core, since equivalent functionality is not near in core yet. It is supposed to be available as a project to figure out, so we are not held up when we get there to put this UI in core. We can choose to not figure this out in parallel and instead hold work up on discussing this later. You've posted mockups above which you got feedback for, but did not respond yet. I think we are still looking for feedback, at least for yours.

Gábor Hojtsy’s picture

Issue tags: -D8MI

Removing D8MI tag as discussed above. Core UI will likely be very different / simpler.

Bojhan’s picture

This fell of my radar, but for those reading the general approach we want for this in core is:

Add a page to "Available updates"
Add a column to Update report page

The page itself would be significantly more simple than the one posted above, we don't want to allow per module updates of translations. We just want to allow updating per language, of everything at once.

Gábor Hojtsy’s picture

@Bojhan: Hm, you wanna mock that up quickly? That would help us get someone start a prototype. :)

Bojhan’s picture

Assigned: Sutharsan » Bojhan

Yes, I am going to assign it to me - and work on it, will take me some time though.

Bojhan’s picture

I have updated the screens for the new simplified scenario, I still want to do a unified updates page - but in case thats out of scope a separate page to do this is fine.

Its basically a table, that only shows the language, clicking/entering upon Details you get more information specifically which module is getting updated.

A message on the status report page.

Bojhan’s picture

Assigned: Bojhan » Unassigned
Status: Needs work » Needs review

Feel free to ping me when the technical side is there.

Sutharsan’s picture

This design looks fine with me. The module version in the details ("This applies language updates to:") may not be very usefull. Locale module tries to download the latest translation for the installed release. The version numbers are always equal. However there is an exception in which it may be usefull to show the translation version number. When a dev-release module is installed, Locale will download the translation of the latest stable release (no po files are available for dev releases).

Gábor Hojtsy’s picture

@Bojhan: The integrated update screen looks interesting... I think it looks good, however, you generally might want to do more translation updates here than module updates. Module updates here could easily screw your site, translation updates are much safer. So I think we are grouping a scary operation with a relatively safe operation, which is my only itchy feeling about it. Otherwise the integration looks cool. The site status page stuff is totally good.

wusel’s picture

The update screen looks very fine.

But I think it would be nice, if we could decide on that screen, to update each module to a dev or a normal version of the module.

Bojhan’s picture

@Sutha feel free to remove version numbers from implementation.

@Gabor I agree, but there is no real difference to the user. Hence why I grouped this functionality together, I'd rather have one page where people actually go that's a bit less save - then several pages, where people never go.

@wusel I think thats out of scope, nor really part of this issue. We don't really want to do per module, as that's more of a contrib usecase.

Bojhan’s picture

Issue tags: -Needs usability review

Removeing tag

podarok’s picture

agree with #64 @Gábor
Module updates have to be in other place (second tab) with possibly even different access permission

Jose Reyero’s picture

I am not sure it is a good idea mixing translation updates with module updates.

Q: Can one of them run without the other?

In my scenario, language updates are run usually automated while module updates are done through git so I never really have the update module enabled in a production site, while I may have the l10n_update running.

Anyway if you want to mix them (which may make some sense I'm just a bit surprised) I'd move translation updates to the second tab and keep on the modules update page a *single and big* checkbox:

[ ] Update module translations too

Gábor Hojtsy’s picture

For Drupal 8 the plan is not to copy-paste a significant chunk of code from update module but to rely on it for the integrated l10n_update code. Unless someone works on refactoring that code to some reusable class, in which case, we can just use that instead of requiring the module to be enabled. (But we don't plan to do that so far).

Gábor Hojtsy’s picture

Title: Simplify translations update page » Translations update feature user experience
Project: Localization update » Drupal core
Version: 7.x-1.x-dev » 8.x-dev
Component: User interface » locale.module
Status: Needs review » Postponed
Issue tags: -montreal +D8MI, +language-ui

Moving this to the core queue finally. Marking postponed however on #1627006: Collect project information for translation update.

penyaskito’s picture

Status: Postponed » Active

This has been unblocked then.

Gábor Hojtsy’s picture

Status: Active » Closed (duplicate)

Implementation of this is in fact happening in #1804702: Display interface translation status.

Gábor Hojtsy’s picture

Issue summary: View changes

Adding parent