STR 3289: i18n and Fluid, does anyone use cross platform internationalisation?

[melcher....@googlemail.com]

Looking at STR 3289, I don't know much about adding another language to an app, neither with POSIX catguts, nor GNU gettext. Both seem to be in use, but can anyone give me a hint on how these are applied across our supported platforms?

The most obvious thing to prove that Fluid can do i18n would be a German version of Fluid, however, I assume, libraries need to be installed, and breaking the Fluid build process is the last thing I want to do.

Can anyone give me pointers on how these tools work cross platform, and how this could be integrated without breaking anything?

Thanks,

 Matthias

[Lauri Kasanen]

I use gettext but only on Linux. I hear on Windows you'd install
http://gnuwin32.sourceforge.net/packages/gettext.htm
and on Mac presumably it can be found in homebrew/etc.

- Lauri

[Albrecht Schlosser]

On 12/10/21 2:01 AM 'melcher....@googlemail.com' via fltk.coredev wrote:

Looking at STR 3289, I don't know much about adding another language to an app, neither with POSIX catguts, nor GNU gettext. Both seem to be in use, but can anyone give me a hint on how these are applied across our supported platforms?

Neither do I but I have had to add translations to a web site which used i18n in a similar way.

The most obvious thing to prove that Fluid can do i18n would be a German version of Fluid, however, I assume, libraries need to be installed, and breaking the Fluid build process is the last thing I want to do.

I don't think that the fluid build process would be affected in any way for implementation of this feature for users. But yes, translations of fluid itself would require additional libs and introduce dependencies. Fluid translation would be too much work. IIRC you need to change the source code to "mark" all strings that are subject to translation, e.g. change "YES" to _("YES") or something like that. A simple example project would be much more helpful.

Actually '_' is a name of a function that is called to translate the text "YES" to "JA" in German.

This translation is based on translation tables that map the original English text to any other language. This is done with external file types .po and .mo.

There's a commandline tool named xgettext ("Extract translatable strings from given input files.") whose manpage might be a start to learn what's going on. I forgot much of it again since I checked that.

I believe the "write strings" menu in Fluid is related.

What you would do (AFAICT) in a real application is:

(1) extract all translatable strings out of the source files (and somehow .fl files or the written "strings" too), likely using xgettext.

(2) build a translation table (.mo or .po, don't know) for any language

(3) anybody may edit the translations for their particular language

(3a) I'm not sure if these translations must be "compiled" in any way.

(4) the program accesses the translation table at startup and whenever a source string needs to be translated.


This is a high level (low knowledge) description of what I learned about this issue.

I'm not sure how useful the file 'test-xgettext.fl' posted by Nikita Egorov (aka Nikego) is. I gave up.

I wish you good luck and success!

[Gonzalo Garramuño]

El 9/12/21 a las 22:01, 'melcher....@googlemail.com' via fltk.coredev
escribió:

> Looking at STR 3289, I don't know much about adding another language
> to an app, neither with POSIX catguts, nor GNU gettext. Both seem to
> be in use, but can anyone give me a hint on how these are applied
> across our supported platforms?

I can give you advice for gettext as I am using it in my player.

>
> Can anyone give me pointers on how these tools work cross platform,
> and how this could be integrated without breaking anything?
>

xgettext extracts all marked text on a platform.  Normally, this means
all text enclosed in gettext() calls, but this is usually shortened to a
macro like _("untranslated string").  Currently there is an issue with
fluid's menus that get created as a static table, where the gettext()
function cannot be used, so ALL strings need to be extracted which is messy.

What you would do (AFAICT) in a real application is:

(1) extract all translatable strings out of the source/header files
(*NOT* the .fl files), likely using xgettext.  This creates a .pot
translation table.


(2) build a translation table ( .po ) for any language by copying the
.pot file and replacing all second strings.

(3) The translations (.po) files are compiled into .mo files using
msgmerge and msgfmt,

(4) the program accesses the translation table at startup and whenever a
source string needs to be translated.

Here's a CMakeLists.txt file with the macros for the process:


SET( _absPotFile "${CMAKE_CURRENT_SOURCE_DIR}/po/messages.pot" )

##

The command below should not use -a as it extracts all strings. It is
needed for fluid's menus not having a gettext (_) function.

##

ADD_CUSTOM_COMMAND( OUTPUT "${_absPotFile}"
COMMAND xgettext
ARGS --package-name=mrViewer --package-version="$VERSION"
--copyright-holder="Film Aura, LLC" -a
--msgid-bugs-address=ggar...@gmail.com -d mrViewer -s -c++ -k_
${SOURCES} -o po/messages.pot
DEPENDS mrViewer
WORKING_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}"
)

SET( LANGUAGES "es" )  # Only Spanish for now

SET( output_files "${_absPotFile}" )

FOREACH( lang ${LANGUAGES} )

  SET( _moDir "${ROOT_DIR}/share/locale/${lang}/LC_MESSAGES/" )
  SET( _moFile "${_moDir}/${PROJECT_NAME}${SHORTVERSION}.mo" )

  SET( output_files ${output_files} ${_moFile} )

  FILE( REMOVE_RECURSE "${_moDir}" ) # Remove dir to remove old .mo files
  FILE( MAKE_DIRECTORY "${_moDir}" ) # Recreate dir to place new .mo file

 SET( _absFile "${CMAKE_CURRENT_SOURCE_DIR}/po/${lang}.po" )

  ADD_CUSTOM_COMMAND( OUTPUT "${_moFile}"
  COMMAND msgmerge --quiet --update --backup=none
  "${_absFile}" "${_absPotFile}"
  COMMAND msgfmt -v "${_absFile}" -o "${_moFile}"
  DEPENDS ${_absFile} ${_absPotFile}
  )

ENDFOREACH( lang )

ADD_CUSTOM_TARGET(
  "translations" ALL
  DEPENDS ${output_files} ${PROJECT_NAME}
  )