Profile Dialog Window translated to Portuguese

Internationalisation code is also working on Windows. The build environment here is UCRT64, but it should also work well with MINGW64

There are still some strings that needs to be translated. Working on it

The above commits implement internationalisation into Abaddon. This feature will allow users to utilise the application in their native language. It'll also allow contributors to translate the project into other available languages. This closes #308.

Behaviour

The approach used for internationalisation is using gettext to read translated strings of a .mo file, which is usually located at /usr/share/locale/ in Linux systems. The default behaviour for Windows and Mac systems is to load the locale folder from the current directory.

Changes in the project workflow

With this addition, code that has some kind of text being shown to the user will also have to consider i18n. The workflow is not complicated since most cumbersome parts (i.e updating and compiling translations) are done by CMake. Of course, some manual work is still needed, like adding the source file to POTFILES for fetching strings for translation and updating abaddon.pot file.

Workflow

1. Add the source file containing strings to be translated in the POTFILES file
2. Include the <glibmm/i18n.h> header in the source file containing the strings to be marked.
3. Mark strings for translation using the macro "_" (e.g _("I'm going to be translated")). In some cases, string formatting is necessary in contexts where string concatenation is not enough.
4. Update abaddon.pot file by issuing xgettext -f po/POTFILES -o po/abaddon.pot --keyword=_. To merge the changes in existing translation files, just run the build command on the build directory.

i like how this looks :^)
the two things that jump out to me though are
1: markup seems like something that shouldnt be included for translation
2: instead of fmt i think we should use Glib::ustring::compose. its what the docs suggest and probably is safer in case theres any scary utf-8 encoding stuff going on behind the scenes

docs say markup is "probably ok" apparently

as for the build errors
mac: i guess add this before the locale code its erroring on

#ifdef setlocale
#undef setlocale
#endif

linux looks like a package youll probably know

Guys, Linux and Windows builds are working as expected. However. the MacOS build is failing because of a "reference not found" error. I kind of have some idea of what it can be, but I don't want to mess up the commit history with tests. Does anyone have an appropriate solution for this?

What I've found

• Forcing gettext linkage: This might work but I don't think it's a really appropriate solution

if the fix is hacky so be it. if you wanna play around with CI runs without messing up commit history u can just do it on another branch and squash it in when it works

Sorry for taking so long to respond, life stuff. Ok, I'll begin writing code for the Mac port. I will also add i18n code to the add-stage patches

• Fix MacOS incompatibility
• Fix graphical artifacts in auditlogpane.cpp
• Replace fmt::format calls