Localization: ignored translations on some controls (catalog: x-vnd.Haiku-libbe)

[dsjonny]

Some translations looks like ignored (ColorControl, Dragger, ...) on Haiku, however these are translated on Pootle and the catalogs are there: ​https://git.haiku-os.org/haiku/tree/data/catalogs/kits

This is hrev54088 x86_gcc2

[diver]

Looks like there is no DoCatalogs rule in src/kits/interface/Jamfile

[nielx]

It looks like the rule is defined in src/kits/Jamfile:

DoCatalogs libbe.so
	: x-vnd.Haiku-libbe
	:
	AboutMenuItem.cpp
	AboutWindow.cpp
	ColorControl.cpp
	Dragger.cpp
	Menu.cpp
	PrintJob.cpp
	StringForSize.cpp
	TextView.cpp
	ZombieReplicantView.cpp
	;

So there is another neason why the translations are not applied.

[pulkomandy]

The translations in libbe require special handling to load the gSystemCatalog (this can't be done like normal catalogs, however I don't remember exactly why). This is normally called from src/kits/app/InitTerminateLibBe.cpp, is that method still called at the right time?

Since when is this broken?

[dsjonny]

I'm not sure if it was worked ever. :/ I checked the images in the documentation (unfortunatelly I have no time to update all images) and on "old" image, for example the Backgrounds the ColorControl was not translated. This is the same for the replicant's menu.

[pulkomandy]

I'm sure it worked when I wrote this code, but that was 10 years ago. And I admit I didn't keep a close look on it, being mostly bilingual now I don't even notice what's French and what's English :/

[nielx]

How it is supposed to work is like this:

1. ​initialize_after() calls ​https://git.haiku-os.org/haiku/tree/src/kits/locale/InitLocaleKit.cpp#n116 call initialize_locale_kit()
2. which in turn calls ​MutableLocaleRoster::LoadSystemCatalog().
3. it tries to find the signature of libbe.so by going through all the images and checking which one defines the be_app symbol.

I will add by putting some debugging to see whether this function is successful. Without being an expert, my hunch is that this way of matching a symbol's address to one in the elf binary might not work because of Position Independent Code (pic).

[pulkomandy]

PIC is not a problem here. The library may be loaded at a different place every time, but we still know which library is where. In fact, all other catalog strings also use this to find the place B_TRANSLATE is called from, except they use the "locale stub" which generates a symbol of its own instead of using be_app or some other generic symbol.

I would think that there is a problem in the init sequence. Either this code is called too early and other parts of libroot/libbe aren't ready yet, or maybe it isn't called at all.

[nielx]

I can confirm that the initialization code is goes through the steps, and indeed loads a catalog. Next up would be to identify what actually loads.

[dsjonny]

I cannot find related catalogs in the /boot/system/data/locale/catalogs folder. Maybe the translation files are only missing from the Haiku image?

[nielx]

Replying to dsjonny:

I cannot find related catalogs in the /boot/system/data/locale/catalogs folder. Maybe the translation files are only missing from the Haiku image?

I think you're on to something here, they are in the source tree (under data/catalogs/kits) but they do not seem to be compiled and added to the image.

[pulkomandy]

That's strange, the DoCatalogs rule seems properly invoked in src/kits/Jamfile for libbe. But indeed the catalogs are not in generated/objects/catalogs/kits.

But I ran "jam -q catalogs" and they were generated, and I'd have thought that is the target that the build depends on to generate them.

[pulkomandy]

​https://review.haiku-os.org/c/haiku/+/2536

[waddlesplash]

Fix merged in hrev54112.