Reorder element under configuration => Regional and language

Adjusted the weights in the respective hook_menu blocks.

Attached screenshot of how it renders for me.

Patch created.

Note: To recreate, visit admin/modules and enable the Interface Translation and Language modules. List will appear on admin/config.

Patch #4 works for me, after clearing caches.

Attached screenshot

#4 is working and has the same effect that marcoscano's screenshot

This issue was RTBC and passing tests on July 1, the beginning of API freeze.

(tag didn't stick. trying again)

Would alphabetical be better? I'm wondering how the order would change as things are added and deleted from the section if it's decided...

How did you decide on this order? Was it based on what you thought would be used most often in a site that is being built... or something that has been launched for a while and is being used/maintained?

#4 doesn't apply to HEAD any more.

I believe core now outputs new items in desired order:

• Regional settings
• Date and time
• Languages
• Translate interface

Note: To recreate, visit admin/modules and enable the Content translation and Locale modules. List will appear on admin/config.

huh. what changed it?

Oops, this is my fault! I am learning Acquia Dev Desktop and inadvertently loaded D7 by mistake. Will create a path for D8A2 today.

OK, I'm stuck. After installing D8A2 and enabling all the core Multilingual modules (Content Translation, Interface Translation and Language) I only see Regional settings and Date and time formats in the Regional and language section on /admin/config.

hm.

try making sure you have removed your sites active config. I usually remove the whole sites directory.
and also drop the database and reinstall.

Also, use the git clone command in the version control tab for the drupal project:
https://drupal.org/project/drupal/git-instructions

the current head of 8.x is different than the alpha2.

Reroll against HEAD

updating tags

Patch #17 works.

#17: Reorder_element_under_configuration-2003812-17.patch queued for re-testing.

This isn't an API change so we don't need to track that.

But I don't see an answer to YesCT's questions in #9.

Is there a standard for grouped lists like this? I would think that alphabetical is a nice default and the "by priority and topic" from OP is subjective. If there's nothing semantically wrong with what's there now, I suggest we mark this as won't fix - unless someone can find an existing pattern.

The existing pattern is by priority and topic. And that is actually a very sane default from UX standpoint, something that begins W might be used a 100 times more than something that begins with an A, therefor we use priority and topic as a guiding principle see https://drupal.org/node/549094

Thanks for the doc reference. I think the suggested order makes sense.

Works perfect for me :)

I've tested and can confirm that the patch in #19 works.

Cheers,

Here was the error for the test patch:

The test block appears in the custom category. Other DisplayBlockTest.php 102 Drupal\block\Tests\Views\DisplayBlockTest->testBlockCategory()
The second cloned test block appears in the custom category. Other DisplayBlockTest.php 120 Drupal\block\Tests\Views\DisplayBlockTest->testBlockCategory()

Looks unrelated so I'll send it for re-test.

#26: Reorder_element_under_configuration-2003812-26.patch queued for re-testing.

This is how it's seen after the patch

#27 and #28 reported succesful testing, but I'm doubting to RTBC because for sanity maybe we need to use 5 (or 10) multiples for weights.
I will wait for another opinion.

Re-rolled. Also changed the weight from -2 to -5 to use always 5 multiples

Updated issue summary.

Tested with simplytest.me (http://simplytest.me/project/drupal/8.x?patch[]=https://drupal.org/files..., dreditor still not working for me for getting this links and proper commit messages after d7do upgrade).

The order is as expected in the "after" screenshots at the issue summary.

34: Reorder_element_under_configuration-2003812-34.patch queued for re-testing.

I have tested the patch in #38, and it is working for me.

Looks good. Committed and pushed to 8.x. Thanks!