AZJIO wrote: Fri Feb 07, 2025 1:27 amI am not a supporter for the texts to be stored in the executable file. We have 193 countries and a lot of languages. If you use 20 languages, then in any case we ignore the other many languages. Make the best option in one language, and connect the rest of the languages using external files.
There is no doubt that your principle is the right one, Azjio. But here we are in a particular case of a library which must remain autonomous to be easily shareable on a forum. In most cases, this library will be used by programmers who only need a single language and can easily generate the corresponding texts from the examples provided in the code, if they are not already included.
It is rare for a programmer to need to develop an application that works in more than two or three languages, and even when that happens, they rarely aim to cover the entire world.
ChrisR wrote: Fri Feb 07, 2025 2:16 am
I agree, and that's where the limit is for the alternative messageRequester, we can't compete with Microsoft's MUI translations.
Of course. But if the application that uses this library is multilingual, it will not find all of the texts it needs in Microsoft's MUI translations. It will have to, one way or another, manage a translation system.
Let's consider that case! I did so when I developed PBBrowser, which is currently available in four languages and includes and uses the Alert.pbi library we are discussing here.
The texts in Alert.pbi were obviously not the only ones that needed to be available in multiple languages for PBBrowser.
So, as you mentioned, Azjio, these various texts had to be centralized in an external file.
PBBrowser therefore defines another version of the GetTextFromCatalog procedure, which is responsible for retrieving texts from a file. That is why, in this library, this main procedure is enclosed within:
Code: Select all
CompilerIf Not Defined(GetTextFromCatalog, #PB_Procedure)
...
CompilerEndIf
This allows the user to define it differently, before XIncludeFile "Alert.pbi", ensuring that GetTextFromCatalog fetches texts from a file instead of using the default translations included in the code.
In this way, I have tried to reconcile the different ways this library can be used, because I personally use it in ALL my projects. Some of these projects are strictly personal and I have no need for multilingual support. I then simply define the global variable MyLanguage$ in my own language and the default translation suits me very well. Other projects are multilingual and I then define a GetTextFromCatalog procedure which allows me to manage the texts in a separate file. Some projects are not multilingual at the start, but they become so later, and I only have to add a different GetTextFromCatalog procedure so that everything continues to work without having to modify the Alert.pbi library.
The comment at the beginning of the code tries to explain that:
Code: Select all
;- 1. Language settings
;
; All Zapman libraries are now designed to be integrated into multilingual applications.
; It is entirely possible to redefine the 'GetTextFromCatalog()' function in a file
; that precedes this one in your 'IncludedFile' list. This way, you can store the
; different translations of the texts used in your application's gadgets in a
; different manner.
; However, the functions in this section provide a simple (and portable) way to do it,
; and if your language is not included in the list of translated languages, only a few
; lines need to be added to address this omission (look at the end of this section).