Update translated strings

[dlh01]

This aims to improve Fieldmanager's readiness for translation, such as the Italian translation by @enrico-sorcinelli in #508, and address issues raised in that PR and by PHPCS.

The changes here include:

• Edits to strings (36fc58f).
• Ordering multiple placeholders.
• Adding translator comments (c7f2688, a132972).
• Adding a .pot file via grunt-wp-i18n (1d07126) and a call to load_plugin_textdomain() (cef2b3f).
• Using placeholders for untranslatable strings, particularly strings of code (c138f47). I'm uncertain about whether this change is helpful, but I tried to mirror similar changes to <code> tags in core (e.g. https://core.trac.wordpress.org/changeset/39254, https://core.trac.wordpress.org/changeset/35548).

[enrico-sorcinelli]

Hi @dlh01,
It looks good. This PR does the same thing I proposed in mine and moreover fixes all the remaining syntax messages issues and rightly adds a grunt task to generate .pot (I used mine).

Why this PR has not been merged yet to the master?

Then, I could send new one PR for the updated italian .po / .mo files and the i18n PHPunit test that I already wrote.

[dlh01]

@enrico-sorcinelli Thanks for reviewing the changes. I think the PR needs more testing and feedback from FM maintainers and other users before it's merged.

[mslinnea]

Hey @dlh01,
I've started looking into updating this branch and have a question. For some of these merge conflicts, the difference is that in this branch, there are backticks used instead of quotes. For example:

/* translators: %s: property name */
wp_die( esc_html( sprintf( __( 'Tried to refer to user %s which current user cannot edit.', 'fieldmanager' ), "`{$v}`" ) ) );

versus on master branch:

/* translators: %s: user id */
wp_die( esc_html( sprintf( __( 'Tried to refer to user "%s" which current user cannot edit.', 'fieldmanager' ), $v ) ) );

I'm wondering what the reason was to use backticks and whether you still think that's preferable?

[dlh01]

@mslinnea The backticks were (are) an attempt to format the strings with Markdown based on how I thought they might be written as HTML. I'm not particularly wedded to it. It was just something to facilitate consistency among strings across the plugin.