Also, especially if this is a new installation, make sure you have your ownerships/permissions set correctly, otherwise Studio (or Module Loader, or Dropdown Editor) can’t write the new information.
Can you post the exact contents of ./custom/include/language/en_GB.lang.php? it’s probably putting there all the values of that dropdown, not just the new one. So my tip would be to edit a bit the other (pre-existing) items to see if they affect the output on screen.
Maybe you’re just changing the wrong dropdown, and it’s going somewhere else in the UI, instead of where you looking for it…
EDIT: Another tip: if this involves Javascript, you need to run additional option in Admin / Repairs. There’s a JS languages repair there.
I agree, I also think that’s where it should be. It feels like it’s saving the changes to the right language file (en_GB) but using the wrong one (en_us) to read from?
It seems the process going from the Dropdown Editor to the PHP file is working ok
Out issue is between the file and the other place in the UI where you expect to see the string.
So if you edit /custom/include/language/en_GB.lang.php manually, changing one of the labels of the pre-existing items, do you see that item changed in the UI after a reload?
If yes, then you know you’re changing the correct dropdown,
If not, then you need to look for the correct one to change.
Don’t forget my advice above about the JS rebuilds.
Thanks for your time and effort. I restarted from scratch, reinstalled and it’s working as we expect it to: writing to /custom/include/language/en_GB.lang.php and visible on the UI.
I’m following the same setup steps I have always followed so I have no idea what was causing it to mess up.