Need help on Dialog auto sizing

The app that I’m currently working, uses 6 languages, and for this Openfl version with HaxeUI I was planning to use Firetongue, a localization framework from Lars Doucet that seems to be a mature lib, but I was wondering how could I use it in a way that didn’t resort to hard coding each text property, everywhere in the code part or in each custom component, or using the script tag in each xml to do the hard coding there, resulting in a masive spaghetti code (granted that I didn´t give it much tought in the matter and possibly could develop some sort utility functions that could help a little, but it would always be a liitle messy and is not the same as using the localization directly in the xml component part, wich makes more sense…).

What you showed me is exactly what I need, but it’s still as a PR, do you plan to merge it? I could test it, because I will need it soon.

Not merge exactly, but use it as a base to rewrite (a little) as alot has changed since then, so i want to make sure a) it will work nicely and b) i will understand it as ill have to maintain it

Ideally, the locale system would be abstracted out (like everything in haxeui) with a default implementation meaning that (ideally) you could plug other engines in

Can you expand on this a little, maybe with some code / xml samples? Id like to fully understand what you mean, and how maybe a core system could help

Cheers,
Ian

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” :wink:
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?

1 Like

Ok, great, thanks for the detailed explanation, so if im understanding correctly, the way i envision the locale stuff to work should be fine for you, so you would have something like:

<dialog id="dialog1" title="_(DIALOG1_STEPPER_TITLE)">
<hbox>
	<label id="label1" text="_(LABEL1_STEPPER_TEXT)" verticalAlign="center" />
	<number-stepper pos="100" />
</hbox>
</dialog>

And those strings would be inside some .properties file or other format… when the locale changes, or is initially found then those strings would “magically” update themselves. This wouldnt be dissimilar to how the current binding works, outlined here: Better Binding in HaxeUI - although this would be a more specialized version of it

A minor thing is im not sure about the “_(…)” syntax - im not sure i like it - but i guess is not really important

I think thats enough info to start a first iteration, but let me know if you have any more thoughts / ideas… always useful to get as much input as possible when creating a new core sub system :slight_smile:

Cheers,
Ian

Yeah, I think that I read these topic back when you created this, but probably read it diagonally, because I know that we could bind inside the xml component property, but I thought that in custom components we wouldn’t be able to access something that is outside the scope of the custom component class, thus all the code for localization string replacement I wrote before…
I read it again and I see that we could expose outside classes, so we could bind directly in the xml, and so, you are right, we could use Firetongue embeded in the xml property, either way, I think that HaxeUI would benefict in having it’s own localization sub system, in the sense that, this way we don’t need one more added framework and expose other unnecessary classes for BindingManager, and it will be more seamlessly integrated with HaxeUI and xml component system.

Thanks, keep up the good work and soon as you have some news on the matter, I’m in line to test it out.

edit–
Forgot the other matters

Yes, exactly like that, I think it’s a cleaner way of doing the localization

Yeah, _(…) syntax is somewhat “strange”, but I do like the arguments idea from the PR, like _(LABEL1_STEPPER_TITLE, 20), because in this way we could control where to put the 20 in our translated string, as you probably know several languages have sentences that have things swaped around and it’s very important to have control on that. The complete “cherry on top” is having the possibility to bind these arguments like so:

<dialog id="dialog1" title="_(DIALOG1_STEPPER_TITLE)">
<hbox>
	<label id="label1" text="_(LABEL1_STEPPER_TEXT, ${ns1.pos})" verticalAlign="center" />
	<number-stepper id="ns1" pos="100" />
</hbox>
</dialog>

Just an idea…

1 Like

text=“_(LABEL1_STEPPER_TEXT, ${ns1.pos})”

I like it! Altough, in reality it would like be more like:

text=“_(LABEL1_STEPPER_TEXT, ns1.pos)”

Anyways, more than enough to get started.

Cheers!
Ian

Of course, you are right, but you understand what I’m trying to say! :wink:
Please let me know when you have someting. Regards.

:partying_face:

1 Like

Wow!! Looking good! Keep them coming!