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
Comment | File | Size | Author |
---|---|---|---|
#61 | statusreportupdate.JPG | 31.78 KB | Bojhan |
#61 | languageupdatelist.jpg | 75.81 KB | Bojhan |
#41 | TestingCheckboxes.png | 144.95 KB | Gábor Hojtsy |
#32 | datesinupdatestranslation.png | 6.05 KB | Bojhan |
#28 | translationupdate.jpg | 71.57 KB | Bojhan |
Comments
Comment #1
hansfn CreditAttribution: hansfn commentedLooks 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?
Comment #2
Gábor HojtsyI 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.
Comment #3
Sutharsan CreditAttribution: Sutharsan commentedComment #4
BrightBoldI 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.
Comment #5
Gábor HojtsyYes, I think we all agree this page seriously needs improvement, and the maintainer is on board as well :)
Comment #6
Sutharsan CreditAttribution: Sutharsan commentedCollapsed fieldset 'Languages' is not noticed by first users. See #1042168: Bugs detected and locale's support needed
Comment #7
Sutharsan CreditAttribution: Sutharsan commentedComment #8
xpound CreditAttribution: xpound commentedSugestion: Put configs at top of the page and turn collapsible off for all this fields [no need].
Comment #9
Sutharsan CreditAttribution: Sutharsan commentedThis first version is functional but still rough. Test it and give your feedback.
Comment #10
Gábor HojtsyThe screenshot visually looks great. Did not have time to look into the code yet.
Comment #11
Sutharsan CreditAttribution: Sutharsan commentedThe 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.
Comment #12
klonosI 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.
Comment #13
Gábor HojtsyYeah, 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.
Comment #14
Sutharsan CreditAttribution: Sutharsan commentedAfter 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.
Comment #15
Sutharsan CreditAttribution: Sutharsan commentedAnd an image for a quick impression
Comment #16
Gábor HojtsyLooks pretty good visually (have not checked the code).
Comment #17
Sutharsan CreditAttribution: Sutharsan commentedDuplicated by #1025562: List of updated translation contains duplicate/wrong statuses
Comment #18
xpound CreditAttribution: xpound commentedMake it available for D6! :P
Comment #19
Sutharsan CreditAttribution: Sutharsan commentedCommitted to 7.x-1.x.
Comment #20
Sutharsan CreditAttribution: Sutharsan commentedNow to be ported to 6.x.
Comment #21
Sutharsan CreditAttribution: Sutharsan commentedComment #22
Sutharsan CreditAttribution: Sutharsan commentedI 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.
Comment #23
Sutharsan CreditAttribution: Sutharsan commentedAnd a screenshot...
Comment #24
Gábor HojtsyLooks pretty good. I especially like how it prints the server used when it tells you the file was not available.
Comment #25
Sutharsan CreditAttribution: Sutharsan commentedThe 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.
Comment #26
Bojhan CreditAttribution: Bojhan commentedsubscribe
Comment #27
Sutharsan CreditAttribution: Sutharsan commentedI 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
Project status
Remote translation source:
Local translation source:
One or more languages in this project have this state.
Language status
Comment #28
Bojhan CreditAttribution: Bojhan commentedSince 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.
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.
Comment #29
Gábor HojtsyI 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.
Comment #30
Gábor HojtsyAlso I do agree this complicates updating both core and contrib at once.
Comment #31
Bojhan CreditAttribution: Bojhan commentedWe could definitely add dates next to the version numbers.
Comment #32
Bojhan CreditAttribution: Bojhan commentedComment #33
Gábor HojtsyTagging for D8MI.
Comment #34
arunaseva CreditAttribution: arunaseva commentedI 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.
Comment #35
yannisc CreditAttribution: yannisc commentedHaving 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.
Comment #36
Sutharsan CreditAttribution: Sutharsan commented@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.
Comment #36.0
Sutharsan CreditAttribution: Sutharsan commentedAdd parent issue
Comment #37
podaroksubscribe
Comment #38
dboulet CreditAttribution: dboulet commentedSubscribe.
Comment #39
Gábor HojtsyDiscussed a lot at the Montreal sprint. Feedback coming up.
Comment #40
Jose Reyero CreditAttribution: Jose Reyero commentedThinking 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?
Comment #41
Gábor HojtsySo as said, we discussed this a lot here in Montreal. Here is some feedback we had:
Once again, this is feedback from our group discussion of about 4-5 people looking at this screen for about an hour or so.
Comment #42
Jose Reyero CreditAttribution: Jose Reyero commentedGreat 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.
Comment #43
Gábor Hojtsy@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 :)
Comment #44
Gábor Hojtsy@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 :)
Comment #45
Bojhan CreditAttribution: Bojhan commentedAutomatic 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.
Comment #46
Gábor Hojtsy@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?
Comment #47
Bojhan CreditAttribution: Bojhan commentedI 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?
Comment #48
Sutharsan CreditAttribution: Sutharsan commented@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.
Comment #49
Gábor Hojtsy@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?
Comment #50
Bojhan CreditAttribution: Bojhan commentedCan you answer those questions yourself? Seems weird to ask me
Comment #51
Gábor Hojtsy@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.
Comment #52
Jose Reyero CreditAttribution: Jose Reyero commentedI 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.
Comment #53
Gábor Hojtsy@Jose: yes, that is exactly the kind of feedback we need here :) Others agree, disagree?
Comment #54
Sutharsan CreditAttribution: Sutharsan commentedAgree 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.
Comment #55
Bojhan CreditAttribution: Bojhan commentedCan we decide to either move on or postpone this for core?
Comment #56
Gábor Hojtsy@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.
Comment #57
Gábor HojtsyRemoving D8MI tag as discussed above. Core UI will likely be very different / simpler.
Comment #58
Bojhan CreditAttribution: Bojhan commentedThis 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.
Comment #59
Gábor Hojtsy@Bojhan: Hm, you wanna mock that up quickly? That would help us get someone start a prototype. :)
Comment #60
Bojhan CreditAttribution: Bojhan commentedYes, I am going to assign it to me - and work on it, will take me some time though.
Comment #61
Bojhan CreditAttribution: Bojhan commentedI 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.
Comment #62
Bojhan CreditAttribution: Bojhan commentedFeel free to ping me when the technical side is there.
Comment #63
Sutharsan CreditAttribution: Sutharsan commentedThis 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).
Comment #64
Gábor Hojtsy@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.
Comment #65
wusel CreditAttribution: wusel commentedThe 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.
Comment #66
Bojhan CreditAttribution: Bojhan commented@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.
Comment #67
Bojhan CreditAttribution: Bojhan commentedRemoveing tag
Comment #68
podarokagree with #64 @Gábor
Module updates have to be in other place (second tab) with possibly even different access permission
Comment #69
Jose Reyero CreditAttribution: Jose Reyero commentedI 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
Comment #70
Gábor HojtsyFor 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).
Comment #71
Gábor HojtsyMoving this to the core queue finally. Marking postponed however on #1627006: Collect project information for translation update.
Comment #72
penyaskitoThis has been unblocked then.
Comment #73
Gábor HojtsyImplementation of this is in fact happening in #1804702: Display interface translation status.
Comment #73.0
Gábor HojtsyAdding parent