Skip to content

0020: Localization

STATUS

Accepted - Retroactive

CONTEXT

Working with publisher Shopback that desires a localization/translated Offers on an Offerwall. This presented potential for significant revenue gain due to increased traffic. In order to achieve this we had to consider manual solutions to presenting Offer content on said Offerwall with non-English translations.

Considered Options

  • Manual Tech Solution - Custom Pivot Table
    • See more info below.
  • spatie/laravel-translatable
    • Laravel Package that applies traits to a given Laravel model. Allowing that field to store translations.
  • astronomic/laravel-translatable
    • Laravel Package that applies traits to a given Laravel model. Allowing that field to store translations.

Manual Tech Solution - Custom Pivot Table

Instead of using an existing package, we have the option of creating a custom table that stores the translation alternative of a given model. For example, this table below details how creating a table for translations of Campaign Offerwall Creative would look like.

campaign_offerwall_creative_translations
---

id - PK
campaign_offerwall_creatives_id - FK to campaign_offerwall_creatives
locale - 'es', 'de'
offer_name
offer_description
offer_instructions
offer_short_description
offer_tip
created_at
updated_at

DECISION

Option 1 (Manual Build) presents as likely unnecessary and would have taken more time to build for the same result as using a trusted package.

Option 3 (astronomic/laravel-translatable) presents similar to Option 2 (spatie/laravel-translatable) but is not as well-known or widely used.

We went with Option 2 (spatie/laravel-translatable) presents as a Laravel package from a reputable source Spatie that helps store translations in database. When applying the HasTranslations trait to a Model the package then wraps these translations with intelligent accessors to allow getting and or setting different translations for a given translatable field.

Application Code should worry about Application Data

When in discovery, the in-place translation of fields was a concern at first due to the necessity of changing the original field to a JSON field. This would mean that the original value would be lost and not available for future use. However, after further consideration, it was determined that this was not a significant issue as the original value is not needed for analytics or other purposes. The application should only have to worry about Application Data, and not downstream data sources that drive analytics. These downstream sources (see in Datahub) can be updated to ingest the new form as needed.

CONSEQUENCES

  • The spatie/laravel-translatable package will be used to manage translations for the Offerwall.
  • Documentation will be necessary to outline how to go about updating a field to be translatable.
  • Some existing fields will be converted to JSON fields to allow for translations.
  • Downstream data sources may need to be updated to accommodate the new translatable fields.
  • Override getter in Models temporarily (See Below).

Necessary getter Override

When a Model has the HasTranslations trait applied, it overrides the default getAttribute method to return the translation for the given locale. An issue arises when the original field has not yet been updated to be a JSON field and contains a plaintext string value (e.g., "Test Description") instead of the package expected JSON structure (e.g., {"en": "Test Description"}). This being that the getAttribute method will not see a translation and instead return an empty string "" for the given translatable property. To resolve this, we needed to override the getAttribute Accessor in the Model to see if the field is in the correct format, if not, return the original value instead of an empty string.

Once the field and all of its corresponding rows in the database have been updated to the correct format, this override can be removed.

NOTES

References

Original Author

Ben Giese

Approval date

Approved by

Appendix