What I found seems a little out of date. Not sure if works with new Haxe 4.0 rc1
Any suggestions saying what works for you are most welcome.
Thanks!
Ummm… what did you find? 
GitHub archive is 5 years old.
I found a posting thread on Google about this that mentioned that it needed and then later was changed to work with Haxe 3.x
So I am guessing it may need changes to work with Haxe 4.0 rc1 as well.
Then entries from
So also turnwing and textball may fit with what I need to do for 4GL stuff.
For reasons in other posts a solution based on JavaScript is not desirable for Native apps as I intend for as many 4GL supported platforms as possible.
I can proceed with trial and error and see how I like each of the 3 possibilities but perhaps:
Someone is using another approach and is close to publishing a Haxe library ?
And / Or
Someone has already used one of the 3 above and can share some Impressions ?
Or
I had a little experience on Windows with i18n. Approach used the Windows .DLL feature and had a different DLL for each Language that was supported. Also changes to UI were typically needed to allow for differences between presentation of Languages. German for example usually has more characters than English for the same meaning. Another underlying Windows API was with Resource files.
I am also lacking in knowing about Haxe Resource Files:
I think me using Haxe Resource Files to do i18n might be OK.
I like the idea of Haxe compiler embedding the resource as part of the emitted source(s).
That way I could have support for a Default Language even if unable to load other Languages.
But the Examples around Resource Files are Game related and do not see any for i18n.
Someone has already used Haxe Resource Files to do i18n ?
Again I could go trial and error approach (but as they keep telling me) this is the 21st century and I thought posting my Ignorance here helps my path to Haxe Enlightenment. 
The haxe-i18n library you point to looks a bit like this resource util I shared here:
It takes a JSON and transforms it into a strongly typed structure which gets inlined during compilation.
Keeping external language files is probably better for software.
It’s nice but probably isn’t sufficient for software with language-switching capability.
In this case you likely want to wrap a i18n resource localisation (which could still be typed like in my gist but probably based on embedding or loading the language files) in components with live-updating capability so changing the language would update your components’ labels.
Thanks for the Link!
Your approach looks like something I could try.
Thinking ahead…
Suppose I have one Application with 2 separate instances of the 4GL Interpreter running.
1 instance may be running automated tests and Languages change as part of tests
other instance may be more interactive with typical programming stuff like IDE supports.
Unless I am missing something, I think there are some significant potential problems with STATIC Classes / Functions. The only Static classes I have now are 1 Main (or WebWorker) class and a Static class / functions for my early UI that will be replaced by HaxeUI. No problem about Main class BUT could be a Not pretty picture for any below Main in the 4GL itself.
Does your approach Require using Static classes / functions or was this just easier to do in a macro approach ?
The point of this macro is to be static and disappear at compile time.
As I mentioned you probably need a more traditional resource-based approach if you need to support language switching, however the macro is a useful reference if you want to have compile time validation and code completion for your label IDs.
Thanks for your insight!
Thing is, in real world (well at least with react applications) it often does not disappear =/
It doesn’t disappear if you reference “groups” indeed. Only direct leaf values get inlined.
Even without reference, “groups” are kept in my application when their leaves are used.
I’m working on it.
Maybe this is wrong and / or Impractical:
Consider not using the static modifier as part of the macro definition.
Overhead:
Every Haxe source file you wanted to use the macro would use a Local copy within that source file. As one of the macro examples demonstrates you can
I am Guessing that then the macro definition could be in a single Haxe file but the inserted definition itself would not use Static. Perhaps this resolves previous problem. And from my point of view would allow 2 instances of 4GL Interpreter to run without messy “fractional behavior” conflicts.
I wrote turnwing and have used it in a few production apps.
Features: Strongly typed interfaces, flexible ways to load translation files (e.g. embed in code, embed as Haxe Resource, load on-the-fly from filesystem/web, etc)
1 Like
