Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
This one brings-in active path aliases, and an easy interface to edit all aliases of a system path on same page, per language. Pages are redirected automatically to active alias. There are about 4 functions which were moved from common.inc to path.inc(documentation may need changes?). This patch's most inspiration comes from chx's new patch alias interface at http://drupal.org/node/106094. Maybe i should post over there, but didn't want to hijack that thread. Please review code...
Comment | File | Size | Author |
---|---|---|---|
#76 | Path-aliases.png | 139 KB | eigentor |
#72 | drupal7-path-admin-ui_147143.patch | 20.64 KB | Gurpartap Singh |
#72 | Picture 20.png | 58.03 KB | Gurpartap Singh |
#63 | drupal7-path-admin-ui_147143.patch | 21.5 KB | Gurpartap Singh |
#55 | Picture 13.png | 60.46 KB | Gurpartap Singh |
Comments
Comment #1
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedHere's a screen shot of edit interface.
Comment #2
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedJust noticed, chx has updated his issue with 'only' the interface for alias editing, which i assume would be done "better". Maybe I should follow with this patch over there. Will talk to chx about it. Btw, this patch includes the last patch at: http://drupal.org/node/141526
Still would be good if someone reviews the patch, it'll help :)
Comment #3
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedMoving to: http://drupal.org/node/106094
Comment #4
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedBack to this issue as per chx's suggestion, because the above issue discusses some unrelated stuff, like tab or pop-up.
Please review..
Comment #5
ChrisKennedy CreditAttribution: ChrisKennedy commentedDid you address any/all of my comments in #62 from the previous issue?
Comment #6
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedYes, all. Please review, there were some more features to the interface like a "Delete all" button, to delete all aliases for a system path in certain language.
Comment #7
ChrisKennedy CreditAttribution: ChrisKennedy commentedThe system.install update number needs to be incremented.
But when I manually fix that error and try to add a path alias via node/X/edit the alias is never saved.
Comment #8
moshe weitzman CreditAttribution: moshe weitzman commentedVery nice functionality, especially needed for proper SEO.
CODE REVIEW
- i think + if (isset($_POST['op']) && ($_POST['op'] == t('Delete all'))) can be removed in favor of adding a handler just to the delete all button. thats new for fapi3.
- why are we implementing hook_user and hook_comment? does something autocreate aliases for every user and comment? i am missing something here.
- "Optionally specify an alternative URL by which this node can be accessed.". I would remove the word 'alternative', given the fine redirect that this patch does.
Comment #9
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedThis one applies to new HEAD revision.
node/X/edit actually sets the alias, but when editing it shows only active alias. so the alias which you wasn't set as active. With this patch, alias set at node/X/edit will be set as active.
Comment #10
moshe weitzman CreditAttribution: moshe weitzman commentedAlso, I would rather not include all of filter.module this early in bootstrap. did you do that just because we need filter_xss_bad_protocal? if so, consider moving that function to bootstrap.inc instead.
Comment #11
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedA total of 5 functions were needed from filter.module, so rather than moving to path.inc or bootstrap.inc, we just included filter.module. The patch now uses submit handler for Delete all button, the fapi3 way. Also fixed deleting path alias by path ID. hook_user, hook_comment, and hook_nodeapi, are used to delete aliases assigned to comment, user or node path, when they are deleted from database(op=delete), because the comment or user no longer exists, it's of no use keeping the aliases for them.
Comment #12
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedSorry, here is the patch.
Comment #13
moshe weitzman CreditAttribution: moshe weitzman commented- i can only find one minor UI glitch. I see Alias 1 repeated even for the 2nd alias listed for a given node. I actually suggest getting rid of these titles. the system url and new alias titles are helpful, but the numbered ones are not IMO.
- "$_GET['destination']) ? $_GET['destination'] : 'admin/build/path'". can you just try admin/build/path' here. i think the form submission code wil just use destination if it is on the URL. no need to handle it.
Comment #14
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedComment #15
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedSorry, above patch included some jquery.js stuff. Use this instead.
Comment #16
moshe weitzman CreditAttribution: moshe weitzman commentedWorks for me.
Comment #17
Dries CreditAttribution: Dries commentedI haven't looked at the code yet -- I started by looking at the screenshot.
Essentially, I'm confused by the Language drop down menu at the bottom. It's not clear what the current workflow is like, or what would happen if I changed the language drop-down menu. Would that cause duplicate path aliases to be inserted?
My suggestion #1: shouldn't there be a drop down menu next to each alias' textfield? That would provide me with a better overview of all the aliases, and it would allow me to translate aliases faster.
My suggestion #2: shouldn't there be a mechanism to remove a path alias from that list?
My suggestion #3: I'd use this interface on the 'add path alias' page but also in a fieldset in the 'edit node' page.
Comment #18
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedHow the language thing works:
# User chooses a language(in select list) on add alias form. Proper validation is done, if the alias exists in that language. If not, the alias is added to that language.
# Edit screen is by language, i.e. if user is editing aliases for german, he won't see aliases for 'all' or any other languages. On aliases overview table, the edit link under Operations links to
?q=admin/build/path/edit/all/node/1
, where 'all' is language, and the rest part is the system path. say the same for german would be?q=admin/build/path/edit/de/node/1
. The language select list's attribute is set to disabled as here it's just for user's information that he's editing alias for foo.A language select list per alias would really be causing hick ups at validation, or at least it would take lots of code changes, making it hard to review.. :P
# To remove an alias, clear the alias from field and submit. A help text stating that should go in.
# On node edit page, only the active alias is shown and can be set currently. In whole table on that page, user permissions, as currently set, won't let the node owner edit the aliases, he can only add new if he has 'create new aliases' permission. Is it worth displaying the whole table?
Comment #19
Dries CreditAttribution: Dries commentedI still think there is room for UI improvements here. Putting all translations on the same UI really helps when you're the single translator (like many people in Belgium are).
Marking this 'code needs work' until some of these suggestions have been tested/implemented. Thanks.
Comment #20
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedThis patch is just a re-roll. As discussed on IRC, the interface showing language drop downs for each alias field didn't prove well at end user's understand factor. Here's the screenshot: http://img2.freeimagehosting.net/uploads/d9775a8a5a.png It's just confusing for one who just started with these things.
So, chx suggested to have tabs for each language, like an "English" tab would appear on top, clicking which shows aliases for that language, default tab being 'All languages'(all is not every language). It's easy to accomplish this with the new menu system, but in that, we could fetch only the first part(i.e. before a slash), of the source path. i.e. suppose we are on this page ?q=admin/build/path/edit/all/forum/1 and our menu tab item in hook_menu for english language is: admin/build/path/edit/en/%
so that wildcard is only a keyword within slashes, whereas we need all the part of url after that. so that tab would link us to: admin/build/path/edit/en/forum
the reason for explaining this is if there's anyone with an idea for the interface when we are dealing with multilingual aliases? could a feature request be made to menu system to allow a new wildcard which is placed at end of path and it passes the rest part of url to the callback?
only new thing with this patch is, delete operations link in edit path interface, and removed "delete all" button.
Comment #21
alpritt CreditAttribution: alpritt commentedNote: I don't really know how languages work in general in Drupal 6, so this may not make total sense in context. However...
- Languages are all on one page.
- There is a drop down menu next to all the aliases allowing easy selection of language
- It is only possible to select one permanent/default/active URL per language. In other words there will be no error message since it is impossible to enter more than one default per language.
- Aliases and permanent URLs are separated to make it clear they are different.
- Easy to delete aliases (not necessarily a good thing, but hey)
- No need to validate user input for alias language. The drop-down list, next to redirects, only contain languages that have a permanent alias associated with them already.
Comment #22
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedThis one implements using tabs, and works against current HEAD revision. Screen shot coming ahead.
Comment #23
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedthe screenie.
Comment #24
moshe weitzman CreditAttribution: moshe weitzman commentedwould be nice to get this one in D6.
Comment #25
catchI really like both the concept and the UI (tabs version). Would be good to get it in.
Comment #26
dmitrig01 CreditAttribution: dmitrig01 commentedLove it, but patch doesn't apply :x
Comment #27
chx CreditAttribution: chx commentedComment #28
catchfresh 6.x tarball, patched it, installed.
Cannot redeclare system_update_6024() (needs to be 6025)
fixed that manually in system install, patched, installed.
I created two nodes. Added path alias on node add form for each - this was fine.
Went to path admin, added an extra path, worked fine.
Redirect from non-active to active alias is fine. And I love the way it finds existing paths when you add a new one.
Added a third path - WSOD.
admin/build/path/add works
admin/build/path/edit/all/4?destination=admin%2Fbuild%2Fpath - WSOD when I save any changes at all - either a new alias or changing the "redirect to" radio.
Everything about it is great apart from these bugs. Didn't test any of the multi-language stuff at all.
Comment #29
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedWhich of the following interface is better, and simple to understand(for novice starter)?
Screenshot 1
Screenshot 2
Screenshot 3
IMO, 1st one is as simple as it could be, and the basic one.
2nd one too much complicated, although it allows quick and advanced users to complete their task as quickly as possible.
3rd is same as the 1st one, just each language's tab appears at top allowing the user to set aliases for each language under each tab.
so... which one do you vote for? maybe we can get this into core as soon as possible, before there's the next feature freeze.
Comment #30
moshe weitzman CreditAttribution: moshe weitzman commented#3 look good to me. glad we are still working on this.
Comment #31
catchI like #3.
Comment #32
catchShould expand. Last time I tested the patch, #3 was the interface, and it was very, very easy to use and behaved exactly how I'd expect. Massive, massive improvement on the current interface.
Comment #33
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedVery much hopefully this patch covers most of tiny tod bugs, which were caught while testing this time. and hopefully we get this in soon :)
Comment #34
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedReview? :'(
Comment #35
catchFresh Drupal 6.x-dev tarball. Installed first, patch applied cleanly. System update ran with no problems, didn't generate any errors at all while I was going through.
The user interface is a massive improvement on the existing one, I'd go so far as to say it's ergonomic - adding multiple aliases becomes very, very easy, because you immediately see all aliases for a path, so you get an overview of what's there. Also the default radio selections make loads of sense and save some mouse clicks in most situations.
This is considerably better than having to go through over 500 pages of aliases on my current site. There's no way, to find all aliases related to one system path at the moment without looking through manually (the new filter only applies to aliases themselves).
Also, the active path functionality works fine, is 100% necessary for these UI improvements, and also sits well with possible path lookup optimisations elsewhere in the queue (splitting out of 'object' paths etc.).
Comment #36
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedComment #37
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedSorry the above patch included outdated .htaccess changes. And screen shot, of what we have without the locale module, to follow in next post.
Comment #38
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedScreen shot of interface, with locale module disabled.
Comment #39
Stefan Nagtegaal CreditAttribution: Stefan Nagtegaal commentedFirst of all, nice patch!
I tested the patch on latest HEAD and this really make things straight forward. I cannot come up with any improvements about coding style, (error) messages or any functionality this patch offers that isn't the way I expected it to be.
So, I'm setting this RTBC..
Very nice!
Comment #40
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedFixed a minor bug in hook_nodeapi. Language was not being set for aliases when inserting or updating.
Thanks for the review Stefan!!
Comment #41
Dries CreditAttribution: Dries commented* I like screen #2 best. It makes it faster to manage multi-lingual content. Belgian translators have asked me for _exactly_ this UI.
* Looking at the screenshot, the page title looks wrong. It should probably be 'Edit $path' or something.
* Patch no longer applies.
Comment #42
alpritt CreditAttribution: alpritt commentedAsking people what UI they want is never going to lead to something they actually do want. Most people are not UI designers. I presume what they actually want is an easy to grok, but fast and efficient interface. They are not going to get that combination with any of these options.
Option 2 would be a compromise with a bias towards speed of operation. But it is completely non-intuitive, so you are serving up another learning curve with this. Make sure you are aware of the dichotomy here.
Comment #43
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedCan we run the Advanced Path alias edit interface as a contrib :P
i was confused using that interface too. if you really have more thumbs for that interface, then will update the patch as soon as possible. Need feedback from others please.......
Comment #44
catchI still like #2 for the interface. Don't like the idea of checkboxes in a single language situation for a start (assuming they don't revert to radios if only one language).
Comment #45
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedWaiting for http://drupal.org/node/157510 to get committed.
Comment #46
catchComment #47
Gábor HojtsyThe patch this issue was hold off on got committed, so this might be the time to review this issue. (Not for Drupal 6 unfortunately).
Comment #48
moshe weitzman CreditAttribution: moshe weitzman commentedOK, it was sad we missed D. But lets get this into D7? Anyone up for refreshing this?
Comment #49
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedI'll submit the active alias feature as a separate patch, and only after improved interface patch gets in.
Comment #50
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedComment #51
kika CreditAttribution: kika commentedsubscribe
Comment #52
lut4rp CreditAttribution: lut4rp commentedWish I figured out where its going kaput, but this isn't working out. On patching a clean HEAD, it isn't allowing me to edit any alias or add an alias and gives a 'Page not found' error. Still, going over the code...
Comment #53
basicmagic.net CreditAttribution: basicmagic.net commentedsubscribe
Comment #54
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedNow with compatible path.test.
Comment #55
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedHere's a screenie with some langs enabled.
Comment #57
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedBut the test "Path aliases with translated nodes" works absolutely fine with latest HEAD.
Comment #58
catchComment #60
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedI really don't believe bot's response. Can anyone else confirm this?
Comment #61
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedComment #62
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedComment #63
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedSyncing with HEAD.
Comment #64
chx CreditAttribution: chx commentedYou can use %menu_tail for the argument instead of the func_get_args stuff because then you can keep the one argument passing in which can be doxygen'd and stuff. I severely disliked the breadcrumb mungling, why is that necessary? The system path totally needs to out of the table or separate better it's rahter confusing right now.
Comment #65
cburschkaComments about the screenshot (http://drupal.org/files/issues/Picture%2013_8.png):
- Any AHAH for generating more fields? Having to reload the form for each new alias added or deleted is /so/ Drupal 5. ;)
- The headings are misleading. They claim that "System path" applies to the three paths above, although only the first entry is the system path and the other two are aliases.
Comment #66
Gurpartap Singh CreditAttribution: Gurpartap Singh commented@chx That's truly a hack to come up with a preview. Really, how would I go to avoid "Edit alias" to appear in the bread crumb when Locale module(+ a language) is enabled? Anything inconsistent in hook_menu()?
Comment #67
webchickNote: In order to not influence my interpretation of the screenshot at http://drupal.org/files/issues/Picture%2013_8.png, I have deliberately NOT read this issue for now, since everyone else who sees this screen will be in the same boat later on.
a) I see from the breadcrumbs that this interface is at Administer >> Site building >> URL Aliases. I actually think that it's much more intuitive to do this kind of management *within* the context of the page you are trying to re-locate. IOW, I would expect this interface at node/1/edit, not at admin/build/path.
b) To me, what this screen appears to be lacking is a way for me to specify which of the 3+ paths is the "real" one. Each page should only have one "real" URL, and the remainder should be 301 redirected to it. For example, if I go to http://en.wikipedia.org/wiki/http, it will automatically send my browser to http://en.wikipedia.org/wiki/Http, the "real" URL of the page.
Comment #68
Gurpartap Singh CreditAttribution: Gurpartap Singh commented@webchick
a) That would be too complex for the end user who simply wants an alias for the node being created, where language is chosen contextually. Maybe more complex with permissions checks for (b) (below). And maybe, on the node edit form, some admin may not want to reveal what secondary aliases he/she has set for a node, to users with node edit access. (Remember, that alias might not be the "real" one).
b) That's on the plan of this issue. Patches upto #40 for D6 have had that feature, but I split them and decided to work on them in series.
Comment #70
webchickRight, after reading the issue I realize that this is just for the global path administration interface, not the interface within individual pages. But I still think that we need a way for people to get to this interface *from the node*, rather than forcing people to go to a completely different section of the website. It's fine if it's a tiny link in the URL Alias fieldset or something, but there should be something.
Also, I'm all for the preservation of kittens, but I'm not sure why it makes sense to split this feature along those lines. Making the addition of multiple URL aliases for the same path easier doesn't really make any sense to me unless you can also mark only one of them as the "real" one. Am I missing something here? I admit to not being a translator...
Finally, do you still happen to have a copy of "screenshot #2" from http://drupal.org/node/147143#comment-561310 for comparison?
Comment #71
catchUsers, taxonomy terms, various other paths are all incredibly different to administer url aliases for. So for a UI that's available around the site, it'd be great to find something which will work on any page - or at least include the same widget which is applied to node forms to users and taxonomy terms as well. But that looks like a follow-up issue.
Comment #72
Gurpartap Singh CreditAttribution: Gurpartap Singh commented@webchick I like the idea to link from node/X/edit page. But it would only be useful when editing nodesand will cost a simple query to fetch the pid. Worth it?
This UI along with the "active alias" feature made the patch to be 50 KB in size, which was really hard to manage, since all the re-rolls required only UI related changes and it turned out harder to keep it synced with HEAD.
Here's how I intend to make use of the UI. "Redirect to" is not-so-self-explanatory term, but we'll decide for it on it's turn.
I'm afraid I might have lost screenshot #2. I'll have to search my desktop's hard drive for it. I really regret not posting the patch for the screenshot #2, to keep a track of code.
@Arancaytar Good idea, but I might take that as a follow up issue.
Anyways, rerolled with a new interface to separate actual aliases from "System path" heading. Screenshot attached.
Comment #74
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedOk, I guess the test needs to "add the french language" to pass. Other than that, please review the rest.
Comment #75
Dave ReidFollowing for review later.
Comment #76
eigentor CreditAttribution: eigentor commentedI got a similar Impression as Webchick has. Thinking from a beginners Perspective, this actually adds cmplexity instead of reducing it.
Find attached my commented screenshot, sorry for the confusing array of arrows. Argh, I hope for allowance of inline images on issue followups after d6 redesign...
Will provide a Mockup of what I think is better later.
Comment #77
dmitrig01 CreditAttribution: dmitrig01 commentedI disagree with the blue arrows. how do you know what a path is. this simplifies it IMO.
Comment #78
yoroy CreditAttribution: yoroy commentedWhat baffles me most with this patch is that it doesn't change the bit that seems the most counter-intuitive to me:
1. You get to this page by clicking the 'edit' link next to an alias in the 'URL aliases' page…
"click"…
2. Huh? Change system path?
All signs were indicating that I was going to change the alias, and the first editable thing I get is changing the system path.
Why is this? Is it a more common scenario to change the 'original' that all your aliases are pointing to?
To me, the first thing I'd expect to see is a text field to change the name of the alias that I clicked the 'edit' link for on the previous page.
As there might be more aliases for the same system path, I think the list of know aliases should probably be the first item on this page. bonus points for focussing or sorting on the one you actually clicked the edit link of.
To me the most natural order of actions seems to be:
- change the wording of existing aliases
- add a new alias
- change the sysyem path all listed alias point to.
But I don't visit these screens all to often so let me know if you think that for example changing the system path is a more likely task users want to complete here.
Comment #79
yoroy CreditAttribution: yoroy commentedThis summarizes how I think this ui should work:
Comment #80
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedyoroy that's an excellent work. I had actually done that long time back, just that "add new alias" and "system path" were exposed as editable textfields just like existing aliases.
Where it failed for me was:
1) when setting "active aliases". The interface turned way too cluttered and confusing with checkboxes in first column. The validation checked for only 1 active alias per language.
2) Setting "system path" as default/active path will take effect for "any" language.
but nevertheless the above mock up rocks. I _want_ to work on exactly this thing. Take it as my request to overcome above caveats somehow? :D
Comment #81
yoroy CreditAttribution: yoroy commentedDang, I'm still putting the system path first there. Weird, that's what confused me at first. hmm.
Gurpartap asked me to try and incorporate the functionality of making a certain alias the active one (this means that any alias for the same path also resolves to the active one). Maybe we should name it the "default alias"? A default alias can be defined for each language.
Before looking into that, one more look at the layout without it. Getting tricky with the system alias info, still shown on top but made part of the description…
Comment #82
Noyz CreditAttribution: Noyz commentedYoroy: As I was reading this thread, I was assembling the same UI in my head. Glad I didn't have to put it together. +1
Comment #83
eigentor CreditAttribution: eigentor commentedI'd also say #81 is perfect. The balance is better if the system path is small, like the other paths.
I still wonder under which circumstances it is possible to change the system path. The node you come from: you cannot change its system path.
Go Yoroy.
Comment #84
yoroy CreditAttribution: yoroy commentedand another tag. I have an idea for the 'make active' functionality, will try to post that soon
Comment #85
yoroy CreditAttribution: yoroy commentedWhat I was thinking to do is already showing up in Mark's designs as well:
From here: http://www.flickr.com/photos/mboulton/3569318373/sizes/o/in/pool-903403@N22/
Make it show (and clickable) on hovering the table row
Comment #86
Gurpartap Singh CreditAttribution: Gurpartap Singh commentedAnd is already there in list (and smileys - but not on hover) module that I co-maintain:
Mentioning just if anyone wants to adopt code or images from it. Pretty nifty if this is accepted in core!
Any issue/d7ux blog link where these UI features are being talked about?
Comment #87
elvis2 CreditAttribution: elvis2 commented#81, great work. I agree with others though, that this functionality should be central to the path module, allowing user, taxonomy, node, - anywhere else where aliases can be handed out, to hook into the path module and create aliases.
So, on node/1/edit, near the bottom (I am sure there is a name for this section, I am still new at d7 stuff), your path alias screenshot would be an option, within the node.
If the user is also using tags, on node/x/edit, then path module would sever up an alias option too.
The same goes when on admin/structure/taxonomy/1/add, give the user a path alias option, and if local is installed give them aliases per language.
catch has mentioned the user/x/edit too, letting users change their user name account path. (koodles for the idea). Here too, your path alias mockup could apply.
I think this idea is powerful, but lots of code rewrite to do... I am not sure how likely it is to get this type of functionality into d7... Maybe it should be a goal for d8?
Comment #88
Dave ReidBumping to D8.
Comment #89
gaelicWizard CreditAttribution: gaelicWizard commented+1
Comment #90
Bojhan CreditAttribution: Bojhan commentedyes
Comment #97
jibranDo we still need this after #3007832: Convert custom path alias forms to entity forms? Moved to 9.1.x as it is a new feature and 8.8.x is alpha ready.
Comment #98
BerdirWe did our best to keep the UI just like it was before with the entity forms, so it's not really related to this except that it isn't possible to build such a UI with entity forms.
I'd suggest to won't fix this. More than one alias per system path is IMHO discouraged, except when it is about different translations and the UI doesn't seem to be mention that. The last working screenshots here are 10 years old ;) No idea what was on those redesign screenshots as they don't work anymore ;)
And no comment since 2011 doesn't exactly indicate that people are still interested in this.