STR #2861

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Post Text | Post File ]

STR #2861

Application:FLTK Library
Status:5 - New
Priority:4 - High, e.g. key functionality not working
Scope:3 - Applies to all machines and operating systems
Subsystem:FLUID
Summary:Enabling "Extract gettext" on fluid menus + possibility of static initialization of strings
Version:1.4-feature
Created By:rokan2
Assigned To:Unassigned
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 rokan2
00:22 Jul 15, 2012
fluid-i18n.diff
11k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 rokan2
00:22 Jul 15, 2012
The code as in fluid-1.3 now uses dynamic i18n within a class constructor or function call. However implemented approach does not allow automatic extraction of translated strings to .po files.

Attached patch fixes that as it allows definition of a name of "no-operation" macro, which can then indicate translated strings. For instance by defining this macro as NOOP (in the i18n dialog), following code is added after inclusion of i18n header:

#ifndef NOOP
  #define NOOP(s) s
#endif

and menus are generated as

Fl_Menu_Item menu[] = {
 {NOOP("Item 1"), ... }
 0
};

Note that this addition allows also "static initialization" if the macro is defined (i.e. in i18n header) as actually calling the translation function. In such a case the user should also define
macro FL_USE_STATIC_I18N, in which case the "dynamic" translation is commented out by a preprocessor macro.

To me translation during static initialization is preferable and 1.1 produced simple yet valid and fast i18n code. I believe that the initialization fiasco problems arise for people initializing gettext in the beginning of main(), which is too late. The proper solution is wrapping this initialization at the first use of translation function, then it should work fine.
 
 
#2 AlbrechtS
03:56 Sep 01, 2016
Bumped to 1.4-feature, set priority to 4 (high).

A fix in 1.3.4 would certainly break existing user code.
We hope we can find a better solution in FLTK 1.4.0.

Please see STR #3289 for a summary of related STR's and further actions:
http://www.fltk.org/str.php?L3289
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.