Fix errors saving dropdown option translations

[cairocoder01]

This fixes two issues. The second was found after I fixed the first, so I included them in one issue.

Issue 1

Can't save option translations if the option key contains a hyphen.

• Go to Settings (D.T) -> Fields
• Edit a key_select/dropdown field
• Add an option with a hyphen (e.g. "Type - Subtype")
• Add a translation for the given option (e.g. English: "Subtype")
• Refresh page to view updated options

Expect: Translation is saved for given option
Actual: Translation is not saved. Cause is that the locale is not parsed properly because the code split on a hyphen, expecting no hyphens in the option key.

Issue 2

Saving a translation of a custom option will clear the label property of the option.

• Go to Settings (D.T) -> Fields
• Edit a key_select/dropdown field
• Add any custom option (this doesn't affect default options on default fields, but does affect custom options on default fields. Won't affect faith_status->believer. WILL affect faith_status.custom_option)
• See that option is displayed with Key and Custom Label
• Add a translation for the given option (e.g. English: "Custom!!")
• Refresh page to view updated options

Expect: Custom label stays the same
Actual: Custom label is made to be blank. For custom options on default fields, this causes the option to not show up anymore. It is still in the database but never appears in the UI because it has no label property.

[kodinkat]

@cairocoder01 my findings following a quick review.....

Issue 1

• Holds true for me, as custom option keys with hyphens can now save translations.

Issue 2

• Saving of blank custom labels is no longer possible - Is this the desired functionality?

[cairocoder01]

@kodinkat Thanks for the thorough check. The problem with issue 2 was not intentional. But would be the use case for saving a blank label? Why would anyone need to do that? That's going to potentially cause errors in the UI if there is no label and no translation to override the blank label.

[kodinkat]

@kodinkat Thanks for the thorough check. The problem with issue 2 was not intentional. But would be the use case for saving a blank label? Why would anyone need to do that? That's going to potentially cause errors in the UI if there is no label and no translation to override the blank label.

Agreed; as somewhat of an edge-case; which should not really be encouraged!

May also be a good exercise at a later date/PR, to also tweak some other default keys (for example: age field) and blank default labels.

Anyway, happy with changes and it's a green light from me! 🙂