Yes, and that is also one of the reasons for “choosing” Firetongue and also HaxeUI, because the app makes use of a lot of graphical stuff, and now I’m using openfl, but If one day the performance cannot be optimize anymore with it, I can “easily” change to other engine/framework, like for example kha. If I can use HaxeUI to handle the localization stuff too, it would be the “cherry on top”…
Well I’m not allowed to give details about the app I’m working on at the moment (NDA contract), but I can use my small testing sample code like the one that I’ve put here before. Using the previous dialog window xml:
<dialog id="dialog1" title="Testing number-stepper in a dialog window">
<hbox>
<label id="label1" text="Testing number-stepper in a dialog window" verticalAlign="center" />
<number-stepper pos="100" />
</hbox>
</dialog>
I have two localization strings to handle here (and without having used or tested Firetongue), using a “outside” framework I thought I could do it in two ways:
a) Earlier I tought and said to use the script tag and write a function that changes the dialog1.title and the label1.text to the localization string and then put each component to callback on that function to some onshow event, but I see there isn’t any public fired event that I can use to replace on the fly using the script tag function as callback, at least not for the dialog component, so this “is not the way” 
b1) “hard code” directly in the custom component class, and create a function called for example, localeRefresh, use it on the constructor to make the initial string replacement and then use it as a callback for a custom event like AppEvent.TRANSLATION_LOCALE_CHANGE event to reassign the localization string when the locale is changed:
package com.test.display.ui;
import haxe.ui.containers.dialogs.Dialog;
@:build(haxe.ui.macros.ComponentMacros.build("assets/ui/number-stepper-dialog.xml"))
class CustomDialogStepper extends Dialog {
public function new() {
super();
buttons = DialogButton.APPLY | DialogButton.CANCEL;
localeRefresh(null);
addEventListener(AppEvent.TRANSLATION_LOCALE_CHANGE, localeRefresh);
}
public function localeRefresh(e) {
dialog1.title = tongue.get("$DIALOG1_STEPPER_TITLE","data");
label1.text = tongue.get("$LABEL1_STEPPER_TEXT","data");
}
}
or
b2) centralize all that in a TranslationAsset class of sorts that handle all the string atribution to each component using the id and then have a refresh method that could be called to reassign all the localization string by the callback function when locale is changed;
This is using Firetongue with HaxeUI, probably there’s even better ways like using binding, but in my opinion, the best way to do it is to “embed” the localization in the xml component text or title or in wich property is needed, like the PR that you showned me, this way we keep track on the location of the localization strings, easier to make sure that we don’t make mistakes or forget to localize something somewhere in the code when the app has many xml component, etc. This is my opinion, what do you make of it?
). Thanks.
Works great! 
