Audit translatable strings

[EbonJaeger]

We should audit all the translatable strings in eopkg to make sure that:

1. They are easy to translate
2. ngettext is used where appropriate for strings that need both a plural and singular form, e.g.:

   _("Adding %d packages to blah")

   Should be:

   ngetttext("Adding one package to blah", "Adding %d packages to blah", num_packages)

[ermo]

Ow.

[vaskebjoern]

I'd be willing to help with this issue. When would you describe a text as easy to translate, @EbonJaeger?

[EbonJaeger]

It's hard to find a good guide (or any guide) on this, but this article I think is a decent start. Not all of the points there apply here, but the rest are good to keep in mind.

[vaskebjoern]

I noticed a few things, while looking through the translatable strings.

• There appears to be an inconsistent use of abbreviations, e.g., don't is used occasionally instead of do not or repo instead of repository. Opting for one of the two variants probably makes sense for consistency. The same applies to the use of the word the.

• When listing packages (to be installed or removed), it is technically possible that only one package is listed, but is a singular form needed here?
  _("Following packages will be installed:\n")

• And in a few places eopkg is still referred to as pisi, which has apparently been overlooked, but could potentially be confusing to users.

There are also a few typos in the code. Should I create a separate pull request for that or just fix them together with the strings?

[EbonJaeger]

1. Consistency is good, I agree. I don't really have a preference for which we use, tbh. I'm not sure if avoiding the contractions makes it any easier for translators or not.
2. If we have the package count, we can use the ngettext function, to to which you provide the singular form, the plural form, and the number to use.

What are the typos, exactly? Are they text strings? Are they code comments or variable names? In the case of the latter, that can be done separately.

[vaskebjoern]

Contractions seem to be quite language-specific and are often not directly translatable.

A general guideline appears to be that contractions should be avoided in formal texts, but it may also make sense to think about the intended emphasis. As the contractions are mostly used when something has not happened, emphasising this with a full not could make sense.

Another option would be to substitute phrases such as ‘Can't append to file.’ with different words to avoid potential contractions, e.g., ‘Unable to append to file.’ .

A typo I'd noticed is in the variable destionationDirectory. I'll see if there are any others and create a separate pull request.