Skip to content

Conversation

@nattsw
Copy link
Contributor

@nattsw nattsw commented Feb 10, 2025

Currently (before the custom fields to tables migrations), locales are sometimes saved as "pt-PT" and "pt_BR" due to the API returning the former and us saving the latter through I18n.locale.

e.g. we are seeing the following in the custom fields, which would mean that the table migrations (#201) also have inherited the discrepancies.

#<PostCustomField:0x00007faffb49f798
 id: 12321231,
 post_id: 1231241,
 name: "translated_text",
 value: "{\"en_GB\":\"\\u003cp\\u003eGreat post my friend \\u00...",  # < locale is underscored
...>

# and

#<PostCustomField:0x00007faffb49dfd8
 id: 12313123,
 post_id: 123123,
 name: "post_detected_lang",
 value: "pt-PT", # < locale is hyphenated
 ...>

This PR adds a migration to convert all values to the hyphenated version, ensures we save the hyphenated ones to the db, and introduces a locale_matches? on the translatable models.

content_locale&.detected_locale
end

def locale_matches?(locale, normalise_region: true)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice, I suppose this would be for handling region-specific logic in future.

@nattsw nattsw merged commit 644a165 into main Feb 11, 2025
5 checks passed
@nattsw nattsw deleted the hyphenate-locales branch February 11, 2025 08:04
@nattsw
Copy link
Contributor Author

nattsw commented Feb 11, 2025

Thank you @tyb-talks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants