Remove some untranslatable characters from msgids

[ghost]

Purpose

Improve msgids consistency by removing unnecessary parts.

Context

Partially addresses #194

Left for an upcoming PR:

• removing trailing newlines from msgids
• naming arguments in msgid
• remove any tabulator space

Changes

• Remove trailing spaces from msgid
• Remove untranslatable msgid (the one composed of the "=" char)
• Make the share directory accessible in development environment

How to test this PR

Zonemaster-CLI behavior should not be altered. Running zonemaster-cli --show-testcase --show-module --locale <locale> <domain> with different locale should not alter the header output.

[matsduf]

It is great that you take this first step. Do you plan to create further PRs for the remaining of issue #194?

I have not yet tested, but will do that.

Could you do the same technical updates of the other PO files to relieve the translator from that?

All PO files are planned to be updated in v2022.2.2 so I suggest that this PR is merged after the release to let this PR handle any conflicts. Is that OK?

[ghost]

Do you plan to create further PRs for the remaining of issue #194?

This is the idea. Or someone else could do it. I don't really mind. As long as we're moving forward on this.

Could you do the same technical updates of the other PO files to relieve the translator from that?

Will do. Done.

All PO files are planned to be updated in v2022.2.2 so I suggest that this PR is merged after the release to let this PR handle any conflicts. Is that OK?

This is totally fine for me (even though I don't expect any conflict with the updated msgid).

[matsduf]

Do you plan to create further PRs for the remaining of issue #194?

This is the idea. Or someone else could do it. I don't really mind. As long as we're moving forward on this.

I agree. I had this update in my mind.

Could you do the same technical updates of the other PO files to relieve the translator from that?

Will do. Done.

Thanks.

All PO files are planned to be updated in v2022.2.2 so I suggest that this PR is merged after the release to let this PR handle any conflicts. Is that OK?

This is totally fine for me (even though I don't expect any conflict with the updated msgid).

Maybe not in msgid, but this PR adds empty msgstr that #303 adds as non-empty strings. And this PR updates POT-Creation-Date which is updated by #303 to another value.

All PO files are updated.

[marc-vanderwal]

Just a remark on style: you can have dynamic field widths as arguments to sprintf. These calls to sprintf could then be rewritten as:

sprintf "%*.2f ", field_width(seconds), $entry->timestamp
sprintf "%-*s ", field_width(level), translate_severity($entry->level);
sprintf "%*.2f %-*s ", field_width(seconds), $entry->timestamp, field_width(level), $entry->level;

[ghost]

Thanks for the tip. I've updated the code.

[tgreenx]

LGTM, tested and works as described.

[marc-vanderwal]

Looks good to me too.

[matsduf]

This is fine, but should not be merged until v2022.2.2 has been released and its branch merged into develop branch.

[ghost]

This is fine, but should not be merged until v2022.2.2 has been released and its branch merged into develop branch.

Rebased and removed conflict with develop. Please re-review.

[mattias-p]

I found and created #334 when release testing of this PR.

[mattias-p]

I've successfully tested this as part of release testing for 2023.1.