feat: Translations and Internationalization

[bontiv]

🌍 Add Internationalization Support for Dialog Functions

Summary

This PR introduces comprehensive internationalization (i18n) support for Thinstation's dialog functions, enabling the system to display user interface messages in multiple languages.

Changes

🎯 Core Features

• Translation Framework: Implemented gettext-based translation system in dialog.functions
• Multi-language Support: Added translation files (.po format) for 15 languages:
  • French (fr) - Complete translations
  • Czech (cs), Danish (da), German (de), Spanish (es)
  • Finnish (fi), Croatian (hr), Hungarian (hu), Italian (it)
  • Japanese (ja), Norwegian (nb), Dutch (nl), Portuguese (pt)
  • Russian (ru), Swedish (sv), Turkish (tr)

🔧 Technical Implementation

• Modified dialog functions to use translatable strings with gettext
• Added proper handling for multi-line translations
• Updated build system to include locale files in the base package
• Enhanced .gitignore to properly handle locale build artifacts

📦 Package Updates

• Updated base package build configuration (.unwind, .wind)
• Added gettext dependency to system RPMs
• Created locale directory structure in ts/build/packages/base/build/locale/

Files Changed

• Modified: ts/build/packages/base/etc/dialog.functions - Core translation implementation
• Added: 15 new .po translation files
• Modified: Build configuration files (.unwind, .wind, .gitignore)
• Modified: ts/rpms/system - Added gettext dependency

Testing

The translation system has been tested with French translations. Other language files are provided as templates and can be completed by native speakers.

Benefits

• Improved accessibility for non-English speaking users
• Standardized translation framework for future expansion
• Easy to add or update translations through .po files
• No breaking changes to existing functionality

Notes

• Default language remains English
• Translations can be selected during build configuration
• Framework is extensible for additional languages

[bontiv]

Hi @Doncuppjr,

What do you think about this PR? Is it the best way to internationalize the project?

During my tests, there are still menu entries to translate. This last part might to be the hardest to implement.

[Doncuppjr]

I've never internationalized user interaction strings before, so I can't say if it is the best. If it works it works though, and it so far as I know, it's an accepted and acceptable approach to it. Menu entries.....well, hmmmm, yeah those menu entry files don't really lend themselves towards translation. I'll think on it.

[bontiv]

For menu entry, the internationalization must add localizade string on desktop file:

thinstation-ng/ts/build/packages/xfwm4/build/extra/etc/xfwm4.functions

Line 22 in b30c99d

echo "Name=$title" >>"$LINK"

They might have other strings as:

Name[fr]=Contrôle du volume
Comment[fr]=Contrôle du volume

The logic with /lib64/menu files is hard to translate. Maybe it's a legacy generation script for others window managers on thinstation below 7.0?

Instead of generate .desktop files on xfwm4.functions, it could be less diffucult to let all package put their own desktop files in /lib64/applications/ folder.

[Doncuppjr]

It was a meta data format I think that was made just for TS. In prior versions, there were like 4 different WM's available and each one could read the meta data and output the correct format for whatever wm was in use. That was a long time ago, .desktop is pretty standard these days. I don't mind doing this, but that is not a point release feature change.

[Doncuppjr]

Possibly keep the meta data files, and generate .desktop files during build instead of runtime. That is gonna mess with pkg though....

[bontiv]

Perhaps the best approach to ensure backward compatibility is as follows:

1. Packages can add desktop files to /lib64/applications/ (modernized packages).
2. At runtime, for each metadata entry, check if the file exists in /lib64/applications/. If it does, do nothing. Otherwise, generate the desktop entry in ~/.local/share/applications/ (legacy generation).

[Doncuppjr]

Sometimes there is already a .desktop, and we override it with settings in lib/menu because we want to call it through the pkg management system. Maybe a stand-by location. Render during build and then assemble/check/override the desktop database at runtime.

[bontiv]

Okay, I understand. Thank you. This remaining change is a bit complex. So I release this PR for the dialog translations and open another one for the menu entries.

[Doncuppjr]

I think the move here, is to process /lib/menu/ files during build. The resulting .desktop files can be stored in /lib/menu and the source menu file can be removed after all entries within are processed. Can leave most of the logic in xfwm4.functions, just call functions during build and then call individual functions within to complete the conversion. At runtime, the menu can still be built, but instead of converting /lib/menu/ files, process .desktop files instead.

[bontiv]

The new specifications have been implemented, so the menu can now be translated. I moved the generation of the .desktop file to a separate script (make-desktop-entries in ts/bin). Since the build script was already quite large, I preferred to isolate this functionality in a new file rather than adding more bulk to the existing one.

There are two ways to generate the translated .desktop file:

1. By adding a source="my-source-file.desktop" line to the file located in /lib/menu/.
2. By using a .desktop file that shares the same base name as the file in /lib/menu/.

I tested this with a few packages, and it works correctly. Some adjustments may be needed for other packages.