| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #2861
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| 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: | matt |
|---|
| Fix Version: | 1.4.0 |
|---|
| Fix Commit: | 29531873ea4395a2dc65cefcc28db09569c38c18 |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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 | |
| |
| #3 | matt
17:12 Dec 18, 2021 |
| Fixed in Git repository.
https://github.com/fltk/fltk/pull/343 | |
[ Return to Bugs & Features ]
|
| |
