Wrong detected locale in a brazilian portuguese OS

[renato]

Using another LAF, Java used the corrent pt-BR Locale automatically.

However, using WebLAF, when the LanguageManager initializes, it detects the "portuguese" translation and resets the Locale to only "pt", breaking some internationalization details (ie. the "¤" in number patterns translating to "€" instead of "R$").

If necessary, I can provide the changes to a pt-BR translation, but I think it would still be a problem for other similar situations.

[mgarin]

WebLaF uses custom translation files provided for each supported language, supported languages can be found as constants in com.alee.managers.language.LanguageConstants class.

---

So far there weren't any variations for single language, but I guess this is the case with pt and pt-BR. So far I'm not sure what is the best solution - either to provide a completely separate translation XML file for pt-BR or just add a smart way to vary some of its parts depending on the variation.

For example here is how part of translation XML looks like right now:

<Dictionary name="Web Look and Feel language" prefix="weblaf" author="Alee Software" creationDate="27.04.2012">
    <Dictionary name="Library information frame" prefix="info">
        <record key="title">
            <value lang="en">Library information</value>
            <value lang="ru">Информация о библиотеке</value>
            <value lang="pl">Informacje o bibliotece</value>
            <value lang="ar">معلومات عن البرنامج</value>
            <value lang="es">Información de la Librería</value>
            <value lang="fr">Information sur la bibliothèque</value>
            <value lang="pt">Inflormação sobre a biblioteca</value>
            <value lang="de">Bibliotheksinformationen</value>
            <value lang="it">Informazioni sulla Libreria</value>
            <value lang="tr">Kütüphane bilgisi</value>
        </record>
        <Dictionary name="General information tab" prefix="general">
            <record key="title">
                <value lang="en">General</value>
                <value lang="ru">Общие</value>
                <value lang="pl">Ogólny</value>
                <value lang="ar">عام</value>
                <value lang="es">General</value>
                <value lang="fr">Général</value>
                <value lang="pt">Geral</value>
                <value lang="de">Allgemein</value>
                <value lang="it">Generale</value>
                <value lang="tr">Genel</value>
            </record>
        </Dictionary>
    </Dictionary>
    <LanguageInfo>
        <langInfo lang="en" author="mgarin" info="English" title="English" />
        <langInfo lang="ru" author="mgarin" info="Russian" title="Русский" />
        <langInfo lang="pl" author="sciepa" info="Polish" title="Polski" />
        <langInfo lang="ar" author="Abu Abdullah" info="Arabic" title="العربية" />
        <langInfo lang="es" author="pablovilas" info="Spanish" title="Español" />
        <langInfo lang="fr" author="movierenamer" info="French" title="Français" />
        <langInfo lang="pt" author="esimoes" info="Portuguese" title="Português" />
        <langInfo lang="de" author="trashguru" info="German" title="Deutsch" />
        <langInfo lang="it" author="cR0Ck" info="Italian" title="Italiano" />
        <langInfo lang="tr" author="Tilelook" info="Turkish" title="Turkish" />
    </LanguageInfo>
</Dictionary>

So my point is that a completely new translation can be added under pt-BR key:
(I have removed other languages to highlight only meaningful parts)

<Dictionary name="Web Look and Feel language" prefix="weblaf" author="Alee Software" creationDate="27.04.2012">
    <Dictionary name="Library information frame" prefix="info">
        <record key="title">
            <value lang="pt">Inflormação sobre a biblioteca</value>
            <value lang="pt-BR">Informações sobre a biblioteca</value>
        </record>
        <Dictionary name="General information tab" prefix="general">
            <record key="title">
                <value lang="pt">Geral</value>
                <value lang="pt-BR">Geral</value>
            </record>
        </Dictionary>
    </Dictionary>
    <LanguageInfo>
        <langInfo lang="pt" author="esimoes" info="Portuguese" title="Português" />
        <langInfo lang="pt-BR" author="renato" info="Portuguese" title="Brazilian Português" />
    </LanguageInfo>
</Dictionary>

Or some changes can be made in LanguageManager to support language variations if there are any for the case. Here is an example how that could look like in XML:

<Dictionary name="Web Look and Feel language" prefix="weblaf" author="Alee Software" creationDate="27.04.2012">
    <Dictionary name="Library information frame" prefix="info">
        <record key="title">
            <value lang="pt">Inflormação sobre a biblioteca</value>
            <value lang="pt-BR">Informações sobre a biblioteca</value>
        </record>
        <Dictionary name="General information tab" prefix="general">
            <record key="title">
                <value lang="pt">Geral</value>
            </record>
        </Dictionary>
    </Dictionary>
    <LanguageInfo>
        <langInfo lang="pt" author="esimoes,renato" info="Portuguese" title="Português" />
    </LanguageInfo>
</Dictionary>

In the first case - languages will be considered as completely separate and will have no connection to each other. So even if there are just a few symbols difference between pt and pt-BR a complete translation must be provided for both of them.

In the second case (with some modifications added to LanguageManager) language variations might be applied according to language suffix, -BR in this specific case. Basically - you will need to fill-in pt language translation and can add suffix-related changes which will be used if according language is selected. For example if simply pt was chosen as language - translations with prefix will simply be ignored, if pt-BR was selected pt-BR-marked values will have priority over pt-marked values.

I guess second case might be a better choice to reduce size of language file and simplify it.

---

Also about:

However, using WebLAF, when the LanguageManager initializes, it detects the "portuguese" translation and resets the Locale to only "pt", breaking some internationalization details (ie. the "¤" in number patterns translating to "€" instead of "R$").

This might be happening for the same reason I described in the beginning - WebLaF doesn't know anything about language variations so if you set it to use LanguageConstants.PORTUGUESE language (or it detects it on its own) it will also set default Locale in your application and that affects how various stuff that uses Locale works (like patterns I guess).

So this should also be fixed as soon as variations are considered by WebLaF.

[renato]

The common solution is to have an entirely different translation, AFAIK. Anyway, the other solution is great too.

The real problem here is that, IMHO, it should be possible to use the portuguese translation with a pt-BR locale, which I don't think is possible, currently. And "pt vs pt-BR" being just an example, there are certainly other countries/languagues that will suffer from the same situation.

[mgarin]

I totally agree on this one, that is why I offered the second solution.

It will have a bit more to it (just noticed that I didn't mention that) - it will actually allow you to set translation AND its variation if it is required.

As an example, even if WebLaF only supports base pt translation and you need pt-BR - you can still use it and have appropriate pt-BR locale set. And LanguageManager will simply use base pt translation in that case. But in addition to that - if -BR variations are added in translation for some keys - those will be replacing base pt translation.

So it should be simple-to-use in general.

To summ up - you will only need to use (as an example):

LanguageManager.setLanguage ( LanguageConstants.PORTUGUESE_BR );

to setup pt-BR if it is supported by WebLaF or simply:

LanguageManager.setLanguage ( "pt-BR" );

and even if there are no values for -BR variation this will still be valid if WebLaF supports base language (which is pt in this example).

Same will work for other cases like:

LanguageManager.setLanguage ( "en-GB" );
LanguageManager.setLanguage ( "en-US" );

And of course you will still be able to use base (or general) translation:

LanguageManager.setLanguage ( "en" );

[mgarin]

So I think I will go with the second solution, it should be pretty easy to add, but will provide a good improvement to translation system overall.

[mgarin]

It's been quite a while since I've started working on this one, but today I'm finally at the point where I can post an update on the upcoming changes.

Initially I wanted to do a small pass over the LanguageManager to add a few features including this one, but it ended up as a major revamp that took quite some time.

So, what have changed?

---

1. Proper Locale support

LanguageManager now uses Locale instead of the String language code and will no longer ignore your country choice.

Here is an example of an XML dictionary that uses country codes within its values:

<Dictionary name="WebLaF test dictionary" prefix="weblaf.test">

    <!-- Dictionary with country-related record -->
    <Dictionary prefix="country">
        <record key="record1">
            <value lang="en">English</value>
            <value lang="en-US">US English</value>
            <value lang="en-GB">GB English</value>
            <value lang="ru">Русский</value>
        </record>
        <record key="record2">
            <value lang="en">Other record</value>
            <value lang="ru">Другая запись</value>
        </record>
    </Dictionary>

</Dictionary>

You might notice that I didn't include en-US and en-GB in the second record, but you will still get translation done right even if you have either en-GB or en-US set as the LanguageManager locale.

Basically values without country codes will be used as a fallback. Values with country code can also be used as a fallback but they will have lowest priority when picked. So if you are requesting en-GB translation priority will be: en-GB > en > en-US

---

2. Multiple languages accessible simultaneously

One of the biggest changes coming with the update is possibility to access multiple languages at the same time. Basically you can now request "en", "en-US", "ru", "pt-BR" or any other translations without touching global language stored within LanguageManager.

It is achieved by using separate instances of Language class which basically only keeps Locale within itself and provides you with a full set of methods to access any translations.

Global translations (for language currently selected within LanguageManager) can now be acquired through LM class which by default uses Language instance stored within LanguageManager. You can also modify the static Supplier for Language instance within LM to provide any Language instances you want for global usage. That can be handy if, for instance, you want your Language to be tied to Thread context (we used that approach with one of our web applications already).

LanguageManager API have been changed and it doesn't provide any methods to access translations anymore to avoid any confusion. Also internal structure of Dictionary have been completely redesigned and it now contains multiple internal caches for providing quick access to any records across multiple nested dictionaries.

So let's say we have a dictionary like this one:

<Dictionary name="WebLaF test dictionary" prefix="weblaf.test">

    <!-- Simple record -->
    <record key="record">
        <value lang="en">English</value>
        <value lang="en-US">US English</value>
        <value lang="ru">Русский</value>
    </record>

</Dictionary>

This is how we will access default (current language) translation:

final String text = LM.get ( "weblaf.test.record" );

This is how we will access en translation directly:

final Language en = new Language ( new Locale ( "en" ) );
final String text = en.get ( "weblaf.test.record" );

This is how we will access en-US translation directly:

final Language enUS = new Language ( new Locale ( "en", "US" ) );
final String text = enUS.get ( "weblaf.test.record" );

And this is how we will access ru translation directly:

final Language ru = new Language ( new Locale ( "ru" ) );
final String text = ru.get ( "weblaf.test.record" );

As you might have noticed - we have created quite a few Language instances there, but worry not, there is no overhead there as the only thing Language stores within itself is the Locale you want to request translations for. So you are free to create any amount of Language instances without consuming excessive amounts of memory or processing time.

Simultaneous access to different languages might not be highly useful for desktop application cases since most commonly you have a single language for your UI, but it is extremely useful for some niche cases.

---

3. Default Locale is not forcefully updated anymore

I agree that this was a bad design choice as it did break quite a few things for some specific cases of Locale usage in various applications, so I finally got rid of this code within LanguageManager along with providing appropriate Locale support.

LanguageManager does not change default JVM Locale by default anymore. But if you liked that feature and want to get it back - you can use a special LanguageListener implementation:

LanguageManager.addLanguageListener ( new LanguageLocaleUpdater () );

This will simply update default JVM Locale with the one set in LanguageManager.

---

4. Proper separation between core and ui manager parts

While I always call it LanguageManager - there are actually two main classes that represent language implementation in WebLaF - widely known LanguageManager.java and barely ever mentioned WebLanguageManager.java. The latter was never really used because it never had any functionality to begin with, it only registered some LanguageUpdater implementations related to ui module.

But it will completely change now, WebLanguageManager will now have a big chunk of features which were initially tied to LanguageManager. To be more specific - all features related to UI. With that change I will finally able to untie core LanguageManager from Swing and eventually separate it into language module - just as it was mentioned in #336 issue.

For now module core will still include basic LanguageManager and will include basic translation options. But features like LanguageUpdaters and component-related LanguageListeners will now be in ui module within WebLanguageManager.

I have also made an additional pass through all Web-components to add missing bridge methods for WebLanguageManager so that you can use them directly on the component.

---

5. Proper translation support for lists, combobox, tables and trees

Lists, comboboxes, tables and trees are quite problematic components when it comes down to translating their content. It might be easy to provide translation as values and within nodes, but updating the components appropriately upon any language changes can be quite difficult.

This is why LanguageSensitive interface was added to assist you. Simply implement it in your custom list, combobox, table or tree, any of their renderers or in the data objects used as values or nodes - components will automatically update themselves if something changes within LanguageManager.

Just make sure to return new translation whenever cell value or node value is requested. That simple.

You can check ExamplesTree in DemoApplication - it does exactly that. You can also switch language in demo and that tree will properly update its node sizes.

---

6. Tooltips in Value have been replaced with Text usage

Object Tooltip have been removed. It can now replaced with Text object with three possible states:

• tooltip - Provides tooltip text, tooltip type will be decided by the library
• swing-tooltip - Provides tooltip text for common Swing tooltip
• custom-tooltip - Provides tooltip text for custom WebLaF tooltip

Options TooltipType type, TooltipWay way and Integer delay that were previously available in Tooltip object are removed and no longer available. Default tooltip delay can be configured for all tooltips within TooltipManager, but default tooltip direction will always be determined by library.

If you have any tooltips in your custom dictionaries, for instance:

<Dictionary prefix="sample">
    <record key="tip">
        <value lang="en">
            <text>Hover to see tooltip</text>
            <tooltip>Simple text within JToolTip popup</tooltip>
        </value>
        <value lang="ru">
            <text>Наведите для просмотра подсказки</text>
            <tooltip>Простой текст внутри JToolTip попапа</tooltip>
        </value>
    </record>
</Dictionary>

You might want to replace them with something like this:

<Dictionary prefix="sample">
    <record key="tip">
        <value lang="en">
            <text>Hover to see tooltip</text>
            <text state="tooltip">Simple text within JToolTip popup</text>
        </value>
        <value lang="ru">
            <text>Наведите для просмотра подсказки</text>
            <text state="tooltip">Простой текст внутри JToolTip попапа</text>
        </value>
    </record>
</Dictionary>

If you want to provide some deeper customization for your tooltips - you can do that through a custom LanguageUpdater or through explicitly specifying a custom tooltip with a separate language code, but it is not possible anymore within translations.

This is a reasonable limitation I had to add to avoid LanguageManager interacting with UI code in the core module.

---

7. Mnemonic have been moved from Value to Text

Since there are multiple Text instance you can provide for different state within a single Value it is reasonable to have a separate mnemonic for each Text as the actual translation may vary between different Texts.

Here is a simple example of how it was before:

<Dictionary name="WebLaF test dictionary" prefix="weblaf.test">

    <!-- Old mnemonics -->
    <record key="button">
        <value lang="en" mnemonic="S">
            <text>Select me</text>
            <text state="selected">Release me</text>
        </value>
    </record>

</Dictionary>

And how it works now:

<Dictionary name="WebLaF test dictionary" prefix="weblaf.test">

    <!-- Stateful mnemonics -->
    <record key="button">
        <value lang="en">
            <text mnemonic="S">Select me</text>
            <text state="selected" mnemonic="R">Release me</text>
        </value>
    </record>

</Dictionary>

Of course binding specific states to UI element states is up to developer, but mnemonics can now be properly integrated into different states of the same component if needed.

---

8. Hotkeys are not available within Value anymore

On initial LanguageManager release I tried to push as many features as possible to try them out on actual projects and see which ones will prove to be useful and stay and which will not be widely used and can eventually be removed.

Unfortunately hotkeys are one of the things I decided to exclude from LanguageManager for a few reasons:

• Too obscure
• Hard to customize
• Unrelated to the translations in general (unlike the mnemonic)

And there is also one more reason - there is already a HotkeyManager which should be used for defining hotkeys and shouldn't delegate its work to the other manager. Although its current implementation has a few issues and I am working on fixing them and bringing some additional heavy improvements to it as well.

---

9. Memory and performance optimizations

Previously LanguageManager always stored a separate massive cache of all records added through various registered Dictionarys. That cache generation took some precious processing time at application startup and also used a chunk of memory even if translations were never even requested once.

There were also a few technical issues with updating old caches - you might have noticed that sometimes, if Dictionarys were modified in runtime the cache would still keep old translations.

Well, it's completely different story now - caches are stored within each separate Dictionary instance and only generated on demand whenever some record or translation is requested. All caches are now also properly updated upon any changes within the Dictionary itself. There have been quite a few challenges with this new system I had to overcome, but the result was certainly worth it.

---

These are the major changes coming soon (will be dropping this update in next 2-3 days). There will also be a lot of other minor fixes, tweaks and improvements to other parts of the library coming along.

[mgarin]

All changes mentioned above (and actually a few more) are now available in styling branch.

Going back to issue question - default locale chosen by LanguageManager will now take system country settings into account. Default Locale will not be touched anymore unless you use this code:

LanguageManager.addLanguageListener ( new LanguageLocaleUpdater () );

And you can now also set Locale as language base into LanguageManager instead of simple string, which allows you to specify country properly and it will also be taken into account when translations are selected.