I noticed this bugg today:
When going to admin/config/regional/stringoverrides .. the strings showing up is based on what your current language is.

The bugg occurs when you switch from your current language to new language .. then visit admin/config/regional/stringoverrides again...
The tabs showing up now is cached version but the strings that show up to be edited is current language... The active tab will still say your default language is selected .. but the page will load the actual current language strings .. and when you edit what you now think is your selected tab you actually edit another tabs strings... i see other people in this forum thinking their changes appear on 2 tabs but what they dont realise is its just because the tab showing is cached.

This causes this problem:
in stringoverrides.module in stringoverrides_menu hook ... when we create the settings pages for multiple languages in the foreach, if current langauge is the same as the one we're printing out in the loop we make it MENU_DEFAULT_LOCAL_TASK instead of MENU_LOCAL_TASK .. this is cached so using global $language here wont really work

Fast solution:
Instead of trying to show the current language as the default one when going to admin/config/regional/stringoverrides .. we can make sure the sites default language is ALWAYS the first settings and active tab that appear. my patch simply changes global language; to $language = language_default();

Comments

toelli’s picture

Issue summary: View changes
james.williams’s picture

The previous patch wouldn't apply for me (I have no idea why), but it is exactly what is needed. Here's a re-rolled version.

  • Commit 6d4aba8 on 7.x-1.x by RobLoach:
    Issue #2225633 by james.williams, toelli: Cant save changes - fix
    

  • Commit 6e10319 on 6.x-1.x by RobLoach:
    Issue #2225633 by james.williams, toelli: Cant save changes - fix
    
robloach’s picture

Status: Patch (to be ported) » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.