You know, it's really hard not to be sarcastic about bugs like this.

The directory in which the launcher scripts are found is called "examples". That doesn't mean "use this verbatim, it applies perfectly to all projects for all time." It's a sample to show you the sorts of things that you can do with a launcher script. You're should write your own launcher script and Info.plist and put them in your own VCS as part of your project.

Some applications (mis)use LANG as a substitute for LANGUAGES. If yours doesn't, don't strip off the country code. Not all applications care about the encoding in the locale. If yours does, preserve it.

`defaults read .GlobalPreferences AppleCollationOrder` works correctly on a fully updated MacOS 10.13.3 installation, returning an ISO-639-2 code if "List sort order" is set to something other than "Universal" and "The domain/default pair of (.GlobalPreferences, AppleCollationOrder) does not exist" if it's set to "Universal".

Better written applications don't do this in their launcher scripts at all; instead they handle localization internally with conditionally-compiled code.

> You know, it's really hard not to be sarcastic about bugs like this.

Hello John, this is the first time I write something like what follows and it makes me really sad: I must say I have never encountered such an arrogant behaviour of an open source developer/maintainer like yours.

Why do you think I have reported this issue (or other issues) against gtk-osx? I have apparently found a way to fix it for Geany and wouldn't have to do anything and just use my fixed version. The reason I report various problems upstream (for other open source projects too) - which costs me extra effort and time - is that when I run to an issue, someone else may run into a similar issue and if it gets fixed upstream, it will save his/her time as well.

This in my opinion is a very powerful "feature" of open source. I'm a maintainer of the libchamplain library and I _love_ when people are reporting bugs. It means they are using the library and they have an interest in improving it - seeing a bug report is a good sign, only dead projects see zero bug reports. Of course, some of the bug reports make more sense and some less. I don't always agree with the suggestions and politely explain why it's not a good idea but I always try to be friendly.

Now back to this bug report. I know the launcher script is an example, I'm not an idiot, and of course we have it version-controlled together with some Geany-specific modifications. But people who start using gtk-osx will use this example as a template (there's no documentation of what environment variables have to be set etc. so this is the only way to start) and the better the example is, the easier it will be to start and avoid non-obvious bugs in the future. This is why I reported this issue and your reaction "You know, it's really hard not to be sarcastic about bugs like this" is a completely inappropriate response to an attempt to make life easier to future users of gtk-osx.

And is it really necessary to make idiots from others by sentences like "Better written applications don't do this ..." implying that Geany is a poorly written application because it does things differently? The guys from the Geany project belong among the best developers I have ever worked with. I have a PhD from IT and many years of experience as a developer so I believe I'm not a newbie either. But even if we were just kids who are completely new to coding, it doesn't justify behavior like yours - on the contrary, people with less experience should be encouraged by the open source community. Of course, you as a maintainer of the project will know the code the best and other people's knowledge of the gtk-osx code will be inferior. You may hear the same questions over and over again and they may seem stupid to you but your task as a maintainer should be to pass your knowledge to users who use it for the very first time and help them as much as possible. 

So why do we use the launcher script in Geany? We want to avoid platform-specific code in the sources as much as possible (which I would say is a sign of maintainable applications and the "better"ness of ifdefs is highly questionable) so we are using this "poor" style of using the launcher script for the Mac platform (which isn't the primary Geany platform anyway).

People reporting bugs or suggesting improvements often become contributors of the project (they already bothered and spent their precious time reporting the issue which means they care about the project). Replies like yours will make every possible contributor run away. This is exactly where I am right now - I will keep maintaining Geany's port on the Mac, I may create bug reports if there are critical problems but I'll avoid contacting you or doing anything related to the GTK Mac port as much as possible.

Jiri,

I'm sorry you're offended. Really, I am. 

Now I'll turn the tables on you: You wrote a *bug report*. It says there's something wrong with what I did. You didn't mark it as an enhancement, you didn't offer a patch, you just said "you f**d up, fix it!". I disagree, the examples are fine as-is and you're flat *wrong* about defaults. Had you marked it as an enhancement and provided a patch that explained how different use cases might be treated you would have gotten a different reception. You've been around the block enough times that you should be able to tell a good bug report from a bad one and recognize that this time you wrote a bad one. If getting called on that causes you to decide that you don't want to write any more bug reports then maybe you should consider a different use of your unpaid time.

It's not my concern whether the Geany developers are ignorant, lazy, or deluded about cross-platform coding. There is no such thing as platform neutral code for non-trivial applications; a cross-platform library like GLib can abstract a lot of the work for you, but the conditional compilation is still there so you still have to build and test on all the supported platforms, and you still have to fill in the gaps for the areas like i18n that GLib doesn't do a good job of covering. Falling back to a heavy-weight launcher script is at best a lazy hack. Neither Apple nor Windows expose all of the user l10n to the shell, so no launcher script can do more than the minimum.

Pardon me John but where did I write "you f**d up, fix it!"? I described the problem into which we did run in Geany and which was related to the default launcher from gtk-osx. I finished with

"Inside the Geany bug report I created a quick and dirty fix for (1) and (2) but it should be improved and applied to the other LANG determination methods. So the question is is such an approach correct or do I miss something?"

I wasn't absolutely saying "you f**d up, fix it!". I was only asking you for a quick feedback of the approach I have taken in Geany and if it's something that could be used for gtk-osx. Sure, I could have attached it here too but as I wrote, it was just a quick hack and I was only asking your opinion regarding the approach. If you gave me a constructive feedback, I would have prepared a patch for the gtk-osx project. And from my point of view it is a bug - if the script from examples is to be taken as a template for projects using gtk-osx then LANG not being set correctly is a bug to me.

You keep talking about i18n but did you actually read the bug report? It's not about i18n at all - i18n works absolutely fine. It's about the embedded terminal in Geany which picks the LANG value and the incorrect value affects scripts executed in the terminal.

It's really sad you can't help insulting others by sentences like "It's not my concern whether the Geany developers are ignorant, lazy, or deluded about cross-platform coding". Geany's primary platform is linux - all other platforms are a bonus. And no matter how much I clutter the Geany code with macOS-specific stuff, the result won't look like a native Mac application anyway - one would really have to drop GTK and rewrite it in Objective-C or Swift to get a native-behaving application. There are many GTK bugs, performance problems and GTK applications on Mac will always be a compromise - even though some minor things could be fixed by a native code, the overall non-nativeness will remain and IMO it's not worth making the code less maintainable. You can disagree and it's fine but there's no need for the adjectives you use to describe us.

Don't feel obliged to reply. I don't want this to turn into some war between us and probably won't continue myself in this discussion. You are absolutely right about a different use of my unpaid time. I'll spend it with the ignorant, lazy, and deluded Geany developers who despite all these negatives are fun to work with and will avoid gtk-osx as much as possible.