The PortableApps team has seen a lot of different methods of adapting an application to the OS language. They raised some objections to the way Gramps does this.
Perhaps their input could be solicited to clarify? It would have to be by someone who would understand the answers. … which rules out me.
I read the whole thread, and I don’t see much reasons to solicit their input. The problem was fixed, and when I install Portable Apps with Gramps here, Gramps follows all languages that I set in Portable Apps, like French, German, and English, and then back to Dutch.
This is a bit different from installing Gramps AIO in a Dutch Windows. With that, we had a problem where the installer didn’t read Windows’ language settings, and didn’t install any, so that Gramps fell back to its default language, which is mostly English. This issue was fixed some time ago, so now, with a default install, Gramps AIO speaks Dutch, and there is no easy way to change the language at run time. And even when I change some variable, it won’t speak German to me, because with default settings, only Dutch is installed here.
When you install Gramps inside Portable Apps, there is no dialog asking which languages and help files you want, and the fact that I can later switch languages at will suggests that the installer selects all. And since Gramps AIO comes with all GTK components that are needed, which are part of the OS in Linux, there is no need to install GTK language packs either. Gramps just works in the language that you set in Portable Apps, next time you start it.
One can argue that it would be better to have a language selector inside Gramps, or maybe more than one, so that I can run Gramps in Dutch, and create reports in English or German. But AFAIK, those are things that we can perfectly handle ourselves.
Note that on Linux, Gramps relies on GTK language packs, so when you change settings in Linux, with LANG, its behavior is different, and you may need to install the language pack first.
We can already select a language for reports.
I wasn’t talking about the method that the thread documents.
My interest was Bart’s early critcism “PAL shouldn’t set language without an ini or platform running, but it does. That’s bad design and custom code is needed to circumvent this.”
John Haller (founder of the site) responds that it is demonstratably incorrect because the portable does NOT need custom code to circumvent.
But my curiosity was piqued because Bart.S. has evidently seen other apps doing things a different (and possibly more user-friendly) way.
It is possible that Bart won’t be interested in discussing it further. He is no longer maintaining the GrampsPortable project because we have been incompatible with his target OS (WinXP) since the 5.0 release. The project updated to libraries that are compatible.
Note that John has become the maintainer and isn’t opposed to doing portable beta versions. And a PortableApps beta on a USB Thumbdrive would simplify isolating the beta for testing on Windoze. And simplify testing it in a hardware lab with a lot of Windoze OS flavors.
OK, I get it, but I don’t see a real problem that we need to act on, or something like that, and I run a lot of programs that were made in other countries. In fact, Python might be one of the few programs that’s made in Holland, or was at least invented here. And it was most probably built like Gramps, in English, so even that is a program that needs a translation to show me a Dutch UI, just like my Linux, and Discourse itself.
When I read the thread, I see a lot of opinions, and in my experience, most opinions are boring, so I still see no reason to act. One may think that it’s nice to be able to change languages, like I can in some programs, like My Heritage’s Family Tree Builder, but I still don’t see much of a point for us.
And if there is one, I suggest that John contacts us.
That isn’t the way PortableApps does things. They have too many apps that they work on to volunteer opinions. We would have to invite comment on a specific subject through their forum.
OK, I get it, but I still don’t see much urgency then. I mean, there is a working solution, and in most applications, I can’t switch languages that easy. I just looked at Firefox, and I can switch that to US English with a single click, probably because that’s its native language, but I need to install language packs when I want more. And in Windows, I can’t change the language for Edge or Mail, so why should we bother for Gramps?
UI wise, Gramps is an alien on Windows an MacOS, because of its reliance on GTK, and there are more programs like that, like Ancestral Quest and RootsMagic, which are based on other UI toolkits, and are designed for Windows. And their users seem to accept that.
Is this important enough to act on?
No. Not during a beta cycle!
I mean on a longer term. Some people figure out ways to run other programs from thumb drives, and right now Gramps seems to be the only genealogy program that is included in the Portable Apps platform. Is it something that we feel a need to invest in? And if so, is the language issue important enough then?
FWIW, my opinion is that GUI switchable language is important if only for 1 reason… the majority of development is done in English. If the (wildly varying skill level) developers cannot easily change back & forth to a different language, they will not test their code to check if they have translations working… or if they have used new & unique (and therefore untranslated) labeling on a common feature.
This would help reduce the onerous volume of nearly-identical translation strings sent to Weblate.
And that’s a good point indeed, for me too, because now I often have to guess what a menu will look like in English, which makes it more difficult to respond to messages here. And the same is of course true for users asking them.
One funny example is that the Deep Connections Grampet is named “Verre Relaties” here, which translates back to Far (or Remote) Relations. And you understood what I mean when I asked a question about that.
I saw another from a Spanish speaking user on an Ancestral Quest mailing list, who asked a question about free form and structured fonts. She used Google translate for that, and it turned out that the Spanish fuentes has 11 different meanings, including sources (you can understand that when you think about the word fountain) and fonts. We have a Dutch mineral water called Sourcy, which sounds French, but is actually pumped up and bottled 5 miles from here.
A developer can easily start Gramps in a different language with:
LANGUAGE=he python Gramps.py
Hebrew is a good test because it is RTL and uses a non-Latin script.
This answer is correct but speaks to the point about “wildly differing skill levels” of developers.
It answers the point for experienced (or perhaps event non-newbie) developers. But doesn’t include how/where that statement is used. So a Newbie or hacker looks that that and is baffled.
Does it go in an .ini? Is there a development environment where it is used? Is it a CLI command that works for a single instance or a whole session? Does it change a variable and stays that way until reversed to English? If it has to be reversed, what is the default value to which it should be reset?
I was baffled the first time being told to use Gramps.py to do something. I searched my machine for hours for Gramps.py
At that point, I was hacking… just patching an installer version of Gramps. I was not building from Source. So my installation did not include a Gramps.py file. That only showed up when cloning from GitHub and building from source with the python compiler.
I understand what you say, but as a developer who needs to invest time, or speaking for fellow developers, which is more realistic knowing my contributions, the big question still is: Why would we invest time in this? How does it fit in our Eisenhower matrix?
I know a lot of better things to do, like supporting call names for non-Germans.
Agreed. Moving to ‘Ideas’ category instead.
Just for fun:
Since I have Wine installed in my Linux, I can run Portable Apps in that, meaning that I can run two instances of Gramps on the same desktop. And maybe 3 when I also install Gramps AIO in Wine, but that’s for another time, when I’m really really bored.
Anyway, when I tried this, I found that when I set Portable Apps to German, and start Gramps in that, not all texts are in German, as you can see in the attached screen:
On this, you see my Linux Gramps in the background, running in Dutch, and Portable Gramps in the foreground, running in German. And in the latter most texts are in German, but the Gramplet titles are not. They’re still Dutch, and the same error shows up when I run Portable Gramps in Windows 11.
It may take years before others see this, but it is a real error.
I’ve noticed that some reports allow selection of the Language used when generating output.
Perhaps this could also be in the Gramps preferences for the GUI? Even if it requires a Gramps restart. (Although it would be better if each language was labeled in its native tongue. It is painful trying to find “English” when the GUI is showing “英语 (Yīngyǔ)” in simplified Chinese.)
