Broken customization palette Topic is solved

[GeoMaL]

Hi all,

The following weird issue i noticed recently, applies to Pale Moon 27, 28 and latest 29.
In Pale Moon 25 and 26 i tried, it does not.
If "toolbar.customization.usesheet" = true (default in Mac OS), when entering customization mode,
the iframe containing the palette appears as a very small square, with sides of less than 80px.
This is happening ONLY with greek locale. I looked up for it in my dev profile, where i have all
available language packs for Pale Moon.
So, most likely this is an issue with greek language pack(s), which is inherited between versions.

The first thing in my mind was a broken dtd or property file, but however, the strange thing is
that there is no any related message in browser console.

In first opportunity i will investigate it further, but in mean time would be useful if someone
else could test it, to see if this is happening in general or only in my environment.

Simple steps to reproduce:
1. - Install greek language pack.
2. - In about:config set "general.useragent.locale" = el, or do it your way if you use a locale switcher.
3. - Restart the browser.
4. - In about:config set "toolbar.customization.usesheet" = true.
5. - Enter customization mode.

Please note that, if you reproduce this issue, you will not be able to exit customization mode!
In such a case, try to hit [tab] one or two times and then [enter], or open a new browser window
and restart from there, instead of killing the browser.

[JustOff]

This is a localization error, in particular in "dialog.dimensions" entity in "customizeToolbar.dtd". We will release a fixed language pack for Greek soon, thanks for reporting this.

Tracking in Issue #275 (pale-moon-localization).

Resolved in Version 28.8.4.

[GeoMaL]

I just finished some tests.
This problem indeed was in "customizeToolbar.dtd". Fortunately, it was easy to find because the
dimensions are defined as inline style at the root of the document.
Should be mentioned clearly as a "LOCALIZATION NOTE" that the names of units must not be localized.

Some strings need update, but i will do it later.
My headache now is an other problem as i see, where the toolbar at the bottom is cropped,
not only in Greek:

el-cropped_toolbar.png

de-cropped_toolbar.png

nl-cropped_toolbar.png

es-AR-cropped_toolbar.png

es-MX-cropped_toolbar.png

pt-PT-cropped_toolbar.png

The problem is that, this is not just a matter of changing the width of the window. Even if it was so, it should
been defined after testing, to find the optimum width for each language.
Unfortunately, this is not that simple..
In my tests, using "em" units it's possible to make a good adjustment for various screen scales in windows, but
there are large differences between windows and linux.
Using "ch" units, the differences between windows and linux are smaller, but not between screen scales!
I tried also some other, compatible with Pale Moon, units, like "vw", "rem", "ex" etc, but it was not possible to
achieve an acceptable compromise.
Not to tell what is happening when i dared to try also changing font size and font family..
So, with this method of one setting for all cases, the only way is to set a quite large with, which however
will give unnecessarily wide window in many cases.
After i disappointed of these results, i turned my attention to different direction.
With a small piece of code in "browser.js" (less than 10 lines), this problem can be solved for good, no matter
of language, screen scales, font sizes, platforms etc.
It does not affect the window when there is no problem. Only if the width of the toolbar is larger than the
predefined width of the window, it resizes it dynamically at the moment of loading, giving it the exact width
for the toolbar to fit.
I don't know if the developers are interested for a solution like this. They should in my opinion, since this
"1 setting for all cases" method is only randomly effective, and also, the mechanism of launching this window
is very old. It is exactly the same with this in Pale Moon/Firefox 3.6.

Some other thing i noticed also is an entity in "customizeToolbar.dtd", which is not used for a label in the
structure of "customizeToolbar.xul" or anywhere else: "ENTITY undoChanges.label".
If this is a leftover from the past (most likely), shouldn't be removed?

[Moonchild]

The actual solution is to make sure translations are not overly long for UI controls.

e.g. "Agrerar una nueva barra de herramientas" is totally unacceptable for button text! It's OK for a tooltip but not for an actual button.
Translators really need to take the use of these strings into account and test the language pack in the browser.
It may not be nice from a linguistic perspective but sometimes UI texts need shorthands and abbreviations, or creative re-writing, to not become too long.

Only after that has been done the dialog dimensions should be tweaked (in limited fashion) to take care of any leftover issues for things that simply can't be made any shorter/need adjustment for too much whitespace.

[GeoMaL]

I can understand your point because i have a good experience in translating software,
including extensions and Pale Moon/Firefox.
Your example is a very good one for those who are interested to learn how to localize software,
since it's not enough just a good level of language knowledge for both source and target.

However, there are really difficult cases, where the long strings are inevitable, if we want to not alter the
meaning of the source, potentially leading to misunderstandings and confusions, mostly about new users.
As an example, related to UI of this topic, is this:
"Restore Default Set" -> "Επαναφορά προεπιλεγμένης διάταξης" (in Greek).
What can i do for this? Cut it to "Restore" ("Επαναφορά") ? It's pretty OK as a label for button, but what about
its meaning? "Restore" what?, might think someone, maybe the lastly moved item?, hit it and destroy his UI
configuration, for which he spent hours or days to create.

Although the string in example above is not extremely long, to make it absolutely unacceptable, unfortunately,
by coincidence, there are two other labels in the same toolbar which are somewhat long too.
As you can understand, in such cases the problem starts to arise by putting all labels in a row, as they are placed
in the toolbar.

The other point of interest is the final tweaking, after making the best possible deal on defining the strings.
Under what conditions (or environment if you prefer) to do it, making sure it will be optimal (or acceptable
at least) in all cases?
As i mention in my previous post, i spent hours playing with various css units in windows and linux mint,
under various screen scales.
Have you ever tried this to see what is happening, even in English?
According to results of my tests, my conclusion is that there is no a one, unique tweak, to play well in
all cases.
Eventually, only a small piece of code i added in "browser.js" gave me very good results everywhere.

Now, you may call me perfectionist or "utopian".. Ok, i could admit the first generally, but it's not "applicable"
here since there are huge differences between various conditions.

[Moonchild]

As an example, related to UI of this topic, is this:
"Restore Default Set" -> "Επαναφορά προεπιλεγμένης διάταξης" (in Greek).
What can i do for this? Cut it to "Restore" ("Επαναφορά") ?

I'd say "default set" would be more logical if you have to cut it down, and using shorter words or alternative words to convey the same meaning in the target language. As said creative rewriting (it's a big part of good translation work -- I've done it for 7 years of my career )

[GeoMaL]

Well, i made my heart a stone and crippled the three long labels. This creative rewriting...

Now i try to adjust the dimensions of this dialog, which is not easy.
Supposedly, all things get multiplied/divided by the factor of screen scaling proportional.

However, when i set the width in windows with screen scaling 1 (giving a few pixels as a margin at the end),
there is a large white space when i turn in 1,25 scaling (or 1.5) and also in linux mint with 1.3 text
scaling by default.

Could you please make me a suggestion what to do on this, to make the best possible deal for most users?