Support

We never had a POT file. GNU GetText has many limitations stemming from the fact that it uses a natural language string as its translation key. If you change the original language (fix a typo, change whitespace / punctuation, adjust some HTML property etc) it treats it as a new translation string; this means that such small issues either have to remain unfixed, or the translation across all other languages is invalidated. Moreover, since the source language is almost always English we have the part of speech ambiguity problem, meaning that English may use the same spelling (but often different pronunciation) for a word depending on whether it's a verb, noun, or adjective. If the identically spelled English word needs to be used as a different part of speech within the same translation context —which happens quite a few times in our software— you end up with hilariously wrong translation in languages with grammatically-relevant suffixes like Greek. Moreover, it's really hard to locate a string in the source code, especially if sprintf() is involved. These problems are well-understood for decades.

Akeeba Backup for WordPress has always used INI files for translation. Each individual translation string has a unique key which identifies the application, view, and context it's used in. This solves the invalidation, ambiguity, and location problems.

Look in wp-content/plugins/akeebabackupwp/app/languages. Each language gets its own folder. You can translate as you please.

VERY IMPORTANT! Keep a backup copy of your language folder OUTSIDE of the plugin itself. WordPress stupidly deletes the entire plugin folder whenever you update a plugin. This means that any customisation you do inside the plugin's folder, including translations, will be removed every time you update the plugin through WordPress. This will not happen if you only ever update the plugin through its own updater (the Update Found icon in Akeeba Backup's control panel page).

Some language keys did change from version 7 to 8, and some were added.

You can edit INI files with any text editor. The applications I would recommend are Notepad++ on Windows, BBedit on macOS, Kate on Linux / KDE Plasma desktop, and gEdit on Linux / GNOME.

The only thing you need to keep in mind is that the format is

LANGUAGE_KEY="Human-readable words"

The LANGUAGE_KEY is always uppercase, it is followed by an equals sign, then the human-readable words enclosed in double-quotes. \

You can put spaces before and after the equals sign.

If you need to include double quotes or a backslash in a string, “escape” them with a backslash. For example:

SAMPLE_KEY="The path you are looking for is <code class=\"small\">C:\\Foo Bar\\Something</code>."

This will print our the text:

The path you are looking for is C:\Foo Bar\Something.

The entire thing must be in one contiguous line. If you want to add a line break, use \n in the human-readable text. For example:

TWO_LINES="First line.\nSecond line."

Finally, plurals. Sometimes you will see things like this:

SOMETHING_N="%d cats have been petted."
SOMETHING_N_1="One cat has been petted."

The first line is the generic plural form (when there are more than one items). The second key with the suffix _1 is used when there is only one item. Since you're translating to German that is all you need to know. 

As an aside, if you're wondering why's that, well, there's a backstory. Technically speaking, you can use an underscore followed by a number in the key of language strings depending countable items to have different strings depending on the cardinality (the number of countable items) e.g. _2, _3 and so on. This is relevant in Slavic languages which have a different plural suffix depending the cardinality, e.g. for 2–4 items (e.g. Ukrainian), or 5–10 items (Russian). The only way for translations in these languages to be correct is to give them the option to have different translation strings based on the cardinality, another thing that GNU GetText can't do. That was another reason to use INI files beyond the ones I mentioned above. A very obscure one, but live long enough and you learn that things like that can break someone's experience; bad grammar on someone's screen sticks out like a sore thumb.

That's all there is to it.