i18n: Add translation support for all user-facing strings

[ShedFlu]

Motivation

We are about to use thisplugin in a customers website, when a colleague asked why the checkbox, about whether or not to send notifications when publishing a post, is in english. So I went ahead and wrapped these parts in WordPress' translation functions, but since I would already have to create a PR, I took the opportunity to make the entire plugin translation-ready.

Changes

This PR adds WordPress translation functions to most, if not all, user-facing strings across both the v2 and v3 codebases:

Files Modified:

• plugin index file:
  • added text domain to header
  • migration notice
• V2:
  • v2/onesignal-admin.php - meta boxes, admin notices,error messages
  • v2/views/config.php - all settings page content (that was a big one)
  • v2/onesignal-public.php - amp widget subscription messages
  • v2/onesignal-widget.php - labels and defaults
• V3
  • v3/onesignal-admin/onesignal-admin.php - albels and messages
  • v3/onesignal-metabox/onesignal-metabox.php - meta box content

Implementation Details

• Text domain: onesignal-free-web-push-notifications same as plugin folder name when installed
• Uses appropriate WordPress translation functions (esc_attr__() etc.)
• Adds translator comments for strings with placeholders
• Fixed a typo or two

WordPress.org Integration

Once merged, community translators can add translations that will automatically be distributedto users without requiring translation files in the repo.

Testing

All strings were wrapped according to WordPress' best practices. The plugin should work identically in English, but is now ready for translation into any language.

---

Note: I tried to catch all user-facing strings, but if I missed any, lmk!

---

This change is 

[ShedFlu]

Hi @sherwinski , just checking in on this, and pinging you, in case, that you just haven't seen the PR. Whenever you have time, I’d appreciate a reveiw on these i18n changes. That is, if this is something you think could be a good addition to the projct. Thanks!

[sherwinski]

Thanks for checking in @ShedFlu. Admittedly, I'm not super familiar with WordPress' translation features so to help move this PR along I have a couple of questions:

• how would you recommend testing this PR locally?
• what does the maintenance overhead for these updates look like? Do we just need to be sure to add one of esc_html_e( or esc_html_e( to any text that we add to the plugin code in the future?

[ShedFlu]

@sherwinski ,glad to hear that you are interested.

Testing this pr locally is straightforward, but you won't be able to easily test different languages yet.

The main importance is that this change doesn't break anything, so you can test by testing the plugin's features locally and also checking that the strings are still being displayed correctly. Nothing should change in the UI or functionality

Checking the translations can be done multiple ways. My preferred way is to use WP CLI and run wp i18n make-pot {plugin-path} {output-path} command to generate the .pot file and then open it in a text editor to see if the strings are present. i18n CLI GitHub, Usage Docs and gnu's gettext documentation for more information on the format.

Another option would be to install a plugin like WPML or Loco Translate to see translatable strings in the WordPress admin area or to use a tool like PoEdit, but might be paid or requires a bit more setup.

And yes, you would need to wrap new user-facing strnigs in the appropriate translation functions, to ensure that they are translated. The main ones are esc_html__ and esc_attr__, and __, for safe use in HTML, safe use in attributes (e.g. class) and unescaped text respectively. The variants with the _e suffix (e.g. esc_html_e) will echo the translated string instead of returning it. WordPress has a comprehensive list of I18n functions that you can use to wrap strings.

There should be no maintenance overhead, as it only changes the workflow when adding new text to the plugin. forgetting to do this is not a huge issue. Worst case scenario: A text is still in english.

I hope this answers all your question, but please feel free to ask anything lse.