MacOS menu only partly localized

[Gerhard Mueller]

Using macOS Catalina 10.15.7 and wxWidgets 3.3.0 I see that the standard macOS menu is only partly localized. It is a mismatch of german and english. See examples of the Internat sample attached. The first menu is wrong and the Window menu must called "Fenster" is wrong also.

[Vadim Zeitlin]

On Wed, 18 Jan 2023 02:06:06 -0800 (PST) 'Gerhard Mueller' via wx-users wrote:

GM> Using macOS Catalina 10.15.7 and wxWidgets 3.3.0 I see that the standard
GM> macOS menu is only partly localized. It is a mismatch of german and
GM> english. See examples of the Internat sample attached. The first menu is
GM> wrong and the Window menu must called "Fenster" is wrong also.

I think this happens because wxstd.mo message catalog, where the
translations of the strings remaining in English are defined, isn't found.
You need to make sure it's available.

Setting WXTRACE environment variable to "i18n" will enable trace messages
during message catalog search, which may be helpful to discover why is the
catalog not being loaded.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Gerhard Mueller]

@Vadim

Thank you for answering.

The wxstd.mo catalog for german locale is there and seems to be found because some strings are translated but others not.

Why?

The last wxWidgets version 3.1.7 I have used has worked but after switching to 3.3.0 it does not work anymore as before.

Furthermore please realize it is the sample file Internat delivered with the wxWidgets sources which does not work correct.

Regards

[utelle]

I made a quick check in my test environment. I can confirm that not all strings get translated. However, I have no idea why. Actually, all strings that are contained in the catalog internat.mo get translated properly. Only some entries from wxstd.mo are not handled correctly.

I enabled tracing with WXTRACE=i18n. That showed that wxstd.mo was loaded:

12:53:59: Trace: (i18n) Using catalog "./de/wxstd.mo".
12:53:59: Trace: (i18n) string "Preferences..." not found in locale ''.
12:53:59: Trace: (i18n) string "Services" not found in locale ''.
12:53:59: Trace: (i18n) string "Hide %s" not found in locale ''.
12:53:59: Trace: (i18n) string "Hide Others" not found in locale ''.
12:53:59: Trace: (i18n) string "ctrl" not found in locale ''.
12:53:59: Trace: (i18n) string "Show All" not found in locale ''.
12:53:59: Trace: (i18n) string "Quit %s" not found in locale ''.
12:53:59: Trace: (i18n) string "Preferences..." not found in locale ''.
12:53:59: Trace: (i18n) string "Services" not found in locale ''.
12:53:59: Trace: (i18n) string "Hide %s" not found in locale ''.
12:53:59: Trace: (i18n) string "Hide Others" not found in locale ''.
12:53:59: Trace: (i18n) string "ctrl" not found in locale ''.
12:53:59: Trace: (i18n) string "Show All" not found in locale ''.
12:53:59: Trace: (i18n) string "Quit %s" not found in locale ''.

However, several strings are not found, although they are present in catalog wxstd. Interestingly, different strings than shown in the first posting didn't get translated. No idea, what's going on.

Additionally, I see that the strings in the calendar widget don't get translated.

Regards,

Ulrich

[Vadim Zeitlin]

On Thu, 19 Jan 2023 04:35:55 -0800 (PST) utelle wrote:

u> I made a quick check in my test environment. I can confirm that not all
u> strings get translated. However, I have no idea why. Actually, all strings
u> that are contained in the catalog internat.mo get translated properly. Only
u> some entries from wxstd.mo are not handled correctly.
u> I enabled tracing with WXTRACE=i18n. That showed that wxstd.mo was loaded:
u>
u> 12:53:59: Trace: (i18n) Using catalog "./de/wxstd.mo".
u> 12:53:59: Trace: (i18n) string "Preferences..." not found in locale ''.

So the local hasn't been set (yet?) when these strings are looked up,
which surely explains the problem.

Is your system language German or are you running a command like this:

$ ./samples/internat/internat.app/Contents/MacOS/internat -y -AppleLanguages "(de)"

to ensure that German is used on startup?

[utelle]

Vadim Zeitlin schrieb am Donnerstag, 19. Januar 2023 um 14:55:54 UTC+1:

So the local hasn't been set (yet?) when these strings are looked up,
which surely explains the problem.

Hm, according to the tracing log the wxstd catalog for German was loaded, and thereafter strings were not found.

On starting the internat sample the application asks whether I want to use it in German. I answer "yes". Then wxUILocale::UseDefault() is called and thereafter the translation catalogs are loaded. And only then the error messages about not found translations are displayed. If I remove the German wxstd catalog, many more error messages about missing translations are displayed.

 

Is your system language German or are you running a command like this:

$ ./samples/internat/internat.app/Contents/MacOS/internat -y -AppleLanguages "(de)"

to ensure that German is used on startup? 

My system language is German. The sample is started without any command line parameters.

Regards,

Ulrich

[Vadim Zeitlin]

On Thu, 19 Jan 2023 06:33:35 -0800 (PST) utelle wrote:

u> Hm, according to the tracing log the wxstd catalog for German was
u> loaded, and thereafter strings were not found.

They're not looked up in the correct locale, however, which is why I think
it isn't set yet.

u> > Is your system language German or are you running a command like this:
u> > $ ./samples/internat/internat.app/Contents/MacOS/internat -y -AppleLanguages "(de)"
u> > to ensure that German is used on startup?
u> My system language is German.

My understanding is that under Mac you can't change the UI language once
the application is started, so it will use UI elements (such as e.g. the
buttons in the message boxes) in the current system language, and the only
way to override this is to use -AppleLanguages option which is specifically
recognized by the OS itself (well, its Launch Service component).

However this doesn't explain the problem with the menu items that we're
supposed to translate ourselves... I'd have to debug this to understand
what's going on.

[Gerhard Mueller]

Because it has worked correct in the old version wxWidgets 3.1.7 and now it shows this strange behavior there might have got a bug into somewhere.

[Gerhard Mueller]

By the way please see the Menu2.jpg I have posted in my first posting and see the screenshot of Ulrich above.

So sometimes the one menu items are translated and sometimes other items are translated.

Very strange...

[utelle]

Vadim Zeitlin schrieb am Donnerstag, 19. Januar 2023 um 15:38:51 UTC+1:

u> Hm, according to the tracing log the wxstd catalog for German was
u> loaded, and thereafter strings were not found.

They're not looked up in the correct locale, however, which is why I think
it isn't set yet.

Well, I have set up a clean environment in my new macOS Ventura VM. I used the latest wx master for testing. I attach the i18n trace output as a text file. As can be seen from the trace log the translation catalogs were found, and no messages were issued for missing translations. However, there are still a few untranslated strings in the Window menu:

The English strings for the missing translations can't be found neither in wx sources nor the wxstd catalog. And please note that accordng to the trace log wxTranslation::GetTranslatedString is not called for those strings.

Interestingly, the first submenu level under "internat" menu is completely translated, while the submenu of "Dienste" = "Services" is not translated at all.

Regarding the internat dialog window I have the following observations:

1. The name of the UI schema in English is actually in German
2. Month name and day name abbreviations in the calendar widget are all in English
3. The current date string in the table under the calendar control is missing
   

Unfortunately, my experiences with macOS are limited and at the moment I have no means to properly debug the internat application.

 

u> > Is your system language German or are you running a command like this:
u> > $ ./samples/internat/internat.app/Contents/MacOS/internat -y -AppleLanguages "(de)"
u> > to ensure that German is used on startup?
u> My system language is German.

I tested to force English as the UI language as follows:

$ ./samples/internat/internat.app/Contents/MacOS/internat -y -AppleLanguages "(en)"

The internat dialog window then looks like this:

The UI locale is set to "en_DE", all strings are in English, but date and numbers are formatted according to a German locale.

Kind regards,

Ulrich

 

[Stefan Csomor]

Hi Ulrich

 

> Well, I have set up a clean environment in my new macOS Ventura VM. I used the latest wx master for testing. I attach the i18n trace output as a text file. As can be seen from the trace log the translation catalogs were found, and no messages were issued for missing translations. However, there are still a few untranslated strings in the Window menu:

 

What is your info.plist telling about your supported languages ? In the internat sample you see a template for a info.plist that supports a lot of lanugages, this array will then be matched against your System’s preferred languages, best fit will win and decide in which language to translate the window menu’s entries.

 

Best,

 

Stefan

[utelle]

Hi Stefan,

What is your info.plist telling about your supported languages ? In the internat sample you see a template for a info.plist that supports a lot of lanugages, this array will then be matched against your System’s preferred languages, best fit will win and decide in which language to translate the window menu’s entries.

I built the internat sample using its unchanged Makefile. That is, the resulting info.plist contains the full list of languages from the template. My system language is German, and that's the language that is returned by wxTranslations::GetBestTranslation() resp wxTranslations::GetPreferredUILanguage().

However, AFAICT GetTranslation() is not called at all for the still untranslated strings. All strings that are defined in the internat source code are correctly translated (at least, if a translation is available in the message catalog - and that's not the case for all internat message catalogs). IMHO it seems to be an OS issue, but I have no idea why macOS should use English instead of the default system language (here German).

Regards,

Ulrich

[Gerhard Mueller]

First of all I see I am not the only one with such problems.

However I am still unable to see any rule of the arising faults and so it is difficult for me to fix anything.

Sometimes only a few menu items are not translated and sometimes some other menu items are not translated but always there are some items left for translating.

Why it is not repeatable with always the same menu items?

Regards

[Stefan Csomor]

Hi Ulrich

 

>I built the internat sample using its unchanged Makefile. That is, the resulting info.plist contains the full list of languages from the template. My >system language is German, and that's the language that is returned by wxTranslations::GetBestTranslation() resp >wxTranslations::GetPreferredUILanguage().

 

>However, AFAICT GetTranslation() is not called at all for the still untranslated strings. All strings that are defined in the internat source code are >correctly translated (at least, if a translation is available in the message catalog - and that's not the case for all internat message catalogs).

 

Thanks for looking at this properly, I was somehow on the wrong page of the problem. The strings in the window menu are not provided by us but by the system. In menu.mm MacSetupWindowMenu we are adding our menu items, these should get translated by our translation layer

 

Minimize

Zoom

Bring All to Front

 

The other items are added by the system through the NSApp.setWindowsMenu call.

 

 

Somehow now our own items are not translated anymore … I’ll try to find out what’s happening …

 

Best,

 

Stefan

[Vadim Zeitlin]

On Tue, 31 Jan 2023 18:01:45 +0000 Stefan Csomor wrote:

SC> Somehow now our own items are not translated anymore … I’ll try to find
SC> out what’s happening …

FWIW I planned to look at this soon, i.e. it's something I want to fix
before 3.2.2, but didn't have time just yet.

[Stefan Csomor]

Hi Vadim

SC> Somehow now our own items are not translated anymore … I’ll try to find
SC> out what’s happening …

>FWIW I planned to look at this soon, i.e. it's something I want to fix
>before 3.2.2, but didn't have time just yet.

That's great, I need your help here

There are two issues as far as I can tell

When I have to create a window menu of my own, because there is none in the app, I was using the non-translated string, fixed in:

https://github.com/wxWidgets/wxWidgets/pull/23204

but when building on the command line using

configure --without-liblzma --enable-debug --with-zlib=builtin --with-libtiff=builtin --with-osx_cocoa --with-cxx=11 --enable-intl --prefix="$instdir"

somehow no wxstd-3.3.mo gets created, so the international sample does not have the default message catalog, when doing a msgfmt de.po -ode.mo by hand and adding this file as a wxstd-3.3.mo to the de folder of international sample things are translated properly ...

Thanks,

Stefan

[utelle]

Hi Stefan,

>However, AFAICT GetTranslation() is not called at all for the still untranslated strings. All strings that are defined in the internat source code are >correctly translated (at least, if a translation is available in the message catalog - and that's not the case for all internat message catalogs).

Thanks for looking at this properly, I was somehow on the wrong page of the problem. The strings in the window menu are not provided by us but by the system. In menu.mm MacSetupWindowMenu we are adding our menu items, these should get translated by our translation layer

Minimize

Zoom

Bring All to Front

Yes, that's correct.  And with your PR #23204 " OSX default window menu title i18n" the "Window" main menu entry is also translated correctly

 The other items are added by the system through the NSApp.setWindowsMenu call.

 

Interestingly, your screenshot shows the entries "Fenster auf der linken Bildschirmseite anordnen", "Fenster auf der rechten Bildschirmseite anordnen, "Angeordnetes Fenster ersetzen" obviously in German, while on my system I see English entries "Tile Window to Left of Screen", "Tile Window to Right of Screen","Replace Tiled Window" - even though the UI language of my system is German.

Somehow now our own items are not translated anymore … I’ll try to find out what’s happening …

Do you get error messages when using WXTRACE=i18n?

Since even "International wxWidgets App" is not translated I suspect that the internat message catalog is not found.

 

Regards,

Ulrich

[Gerhard Mueller]

It seems to have been fixed now with commit "Use translation context for more standard OSX menu items, Similar items were added context in d85f0e311d (Use translation context

for standard OSX menu items, 2022-05-02) but some were missed back then." from Lauri Nurmi the 3. Feb. 2023 at15:03

Regards Gerhard

[Lauri Nurmi]

This is unexpected, because that is not something my commit aimed to fix.

--
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/50123ed4-03a4-40f1-b281-3f4932ecb5cen%40googlegroups.com.

[utelle]

This is unexpected, because that is not something my commit aimed to fix.

Well, for me this "fix" does not work. I updated my local wxWidgets repo to the latest master, and rebuilt wx and the internat sample. Running internat with tracing I get the following messages

20:52:13: Trace: (i18n) Using catalog "./de/wxstd.mo".
20:52:13: Trace: (i18n) string "Window" not found in context 'macOS menu name' locale ''.
20:52:13: Trace: (i18n) string "Help" not found in context 'macOS menu name' locale ''.
20:52:13: Trace: (i18n) string "Minimize" not found in context 'macOS menu item' locale ''.
20:52:13: Trace: (i18n) string "Zoom" not found in context 'macOS menu item' locale ''.
20:52:13: Trace: (i18n) string "Bring All to Front" not found in context 'macOS menu item' locale ''.

and the "Window" menu entry and all subentries are not translated. Actually, this is not really surprising, because only the Finnish translation catalog (locale/fi.po) was updated accordingly.

So, before this issue can be called "solved" all translation catalogs, the template "locale/wxstd.pot" and all language specific catalogs need to be updated. Until this is done the situation is worse than before.

Even if the translation catalogs are all updated, there remain entries in the Window menu for which the translation mechanism is not called at all. That is, the OS seems to add entries to the menu which are not captured by wx, and therefore stay untranslated. Unfortunately, I have no idea how to fix that.

Regards,

Ulrich

[Stefan Csomor]

Hi Ulrich

 The other items are added by the system through the NSApp.setWindowsMenu call.

 

Interestingly, your screenshot shows the entries "Fenster auf der linken Bildschirmseite anordnen", "Fenster auf der rechten Bildschirmseite anordnen, "Angeordnetes Fenster ersetzen" obviously in German, while on my system I see English entries "Tile Window to Left of Screen", "Tile Window to Right of Screen","Replace Tiled Window" - even though the UI language of my system is German.

 

Could you post the info.plist of your executable bundle ?

 

Best,

 

Stefan

[Stefan Csomor]

Hi

 

> Running internat with tracing I get the following messages

 

20:52:13: Trace: (i18n) Using catalog "./de/wxstd.mo".
20:52:13: Trace: (i18n) string "Window" not found in context 'macOS menu name' locale ''.
20:52:13: Trace: (i18n) string "Help" not found in context 'macOS menu name' locale ''.
20:52:13: Trace: (i18n) string "Minimize" not found in context 'macOS menu item' locale ''.
20:52:13: Trace: (i18n) string "Zoom" not found in context 'macOS menu item' locale ''.
20:52:13: Trace: (i18n) string "Bring All to Front" not found in context 'macOS menu item' locale ''.

 

And you have copied the wxstd.mo into the sample’s language directory ? or is it there already ? as I wrote I had to do this by hand (both generating and copying) in order for things to work:

 

>somehow no wxstd-3.3.mo gets created, so the international sample does not have the default message catalog, when doing a msgfmt de.po ->ode.mo by hand and adding this file as a wxstd-3.3.mo to the de folder of international sample things are translated properly ...

 

Best,

 

Stefan

[utelle]

Hi Stefan,

> Running internat with tracing I get the following messages

20:52:13: Trace: (i18n) Using catalog "./de/wxstd.mo".
20:52:13: Trace: (i18n) string "Window" not found in context 'macOS menu name' locale ''.
20:52:13: Trace: (i18n) string "Help" not found in context 'macOS menu name' locale ''.
20:52:13: Trace: (i18n) string "Minimize" not found in context 'macOS menu item' locale ''.
20:52:13: Trace: (i18n) string "Zoom" not found in context 'macOS menu item' locale ''.
20:52:13: Trace: (i18n) string "Bring All to Front" not found in context 'macOS menu item' locale ''.

And you have copied the wxstd.mo into the sample’s language directory ?

Yes.

or is it there already ?

No.

as I wrote I had to do this by hand (both generating and copying) in order for things to work:

 I used the file locale/de.po from the wx repository to generate wxstd.mo, and then copied that file to the internat sample's language directory.

I used the latest wx master to compile the sample.

 >somehow no wxstd-3.3.mo gets created, so the international sample does not have the default message catalog, when doing a msgfmt de.po ->ode.mo by hand and adding this file as a wxstd-3.3.mo to the de folder of international sample things are translated properly ...

Due to the modifications of src/osx/cocoa/menu.mm applied by Lauri Nurmi the translation strings now require a context. This is not (yet) reflected in the message catalogs located in the locale directory. That is, the menu strings are currently not found at all. It will be necessary to regenerate wxstd.pot and adjust all translation catalogs.

Please find attached the file Info.plist (as generated by performing make).

Regards,

Ulrich

[Lauri Nurmi]

utelle kirjoitti 4.2.2023 klo 22:18:

and the "Window" menu entry and all subentries are not translated. Actually, this is not really surprising, because only the Finnish translation catalog (locale/fi.po) was updated accordingly.

So, before this issue can be called "solved" all translation catalogs, the template "locale/wxstd.pot" and all language specific catalogs need to be updated.

Were all of the relevant strings translated for _all_ languages in the first place, before the aforementioned commit? I doubt that, but did not check.

Until this is done the situation is worse than before.

If you are implying that any changes in the translatable source strings should be immediately reflected to _all_ translations, even in the development branch, master, then I don't know if using this Gettext-style method for wx's own translations is viable at all.

Doing an automated update for said strings is likely to result in some wrong terminology being used in the translations. And the very reason for the commit to add the contexts was to try ensure that these macOS-specific strings would get translated in a way matching the native macOS translations, and not share translations with other systems that might use different terminology.

[utelle]

Hei Lauri,

So, before this issue can be called "solved" all translation catalogs, the template "locale/wxstd.pot" and all language specific catalogs need to be updated.

Were all of the relevant strings translated for _all_ languages in the first place, before the aforementioned commit?

No, most likely not. However, at the moment correct translation will only take place, if the message catalog is updated as you did for the Finnish catalog.

I doubt that, but did not check.

I didn't check either.

Until this is done the situation is worse than before.

If you are implying that any changes in the translatable source strings should be immediately reflected to _all_ translations, even in the development branch, master, then I don't know if using this Gettext-style method for wx's own translations is viable at all.

Anteeksi, no offense meant.

It is just an observation that the message catalogs need an update after such a source change. That is, wxstd.pot needs to be regenerated, so that all other language specific .po files can be updated based on it. Thereafter translators can adjust the translations, whenever they have time to do it.

Doing an automated update for said strings is likely to result in some wrong terminology being used in the translations.

I fully agree. And automatic translation was not, what I had in mind. However, AFAICS there is already a Makefile in the locale directory doing the steps I meant: (1) regenerating wxstd.po, (2) merge new strings into all .po files (3) optionally create .mo files. What I do not know is, when this Makefile is invoked. Maybe only shortly before a release?

And the very reason for the commit to add the contexts was to try ensure that these macOS-specific strings would get translated in a way matching the native macOS translations, and not share translations with other systems that might use different terminology.

I fully understand your motivation. However, IMHO such changes should be applied to wxstd.pot first, and thereafter to individual .po files. This would make it easier for other translators to update their translations.

 Regards,

Ulrich

[utelle]

[...] However, AFAICS there is already a Makefile in the locale directory doing the steps I meant: (1) regenerating wxstd.po, (2) merge new strings into all .po files (3) optionally create .mo files. What I do not know is, when this Makefile is invoked. Maybe only shortly before a release?

Actually, using that Makefile was a matter of minutes. So, I prepared a PR with the updated .pot/.po files, which was already merged into the wx master. AFAICT the .po message merge process used the existing translations to fill the new context dependent translations. That may not be correct in all cases, but is not worse than what we had before. What Lauri did for the Finnish message catalog, I did for the German message catalog. It is up to other wx translators to check the other message catalogs.

Using the updated message catalogs should deliver better translations for an application's main menu. However, there are still menu entries that are added outside of the control of a wx application which are possibly not translated. I don't know enough about macOS to tell whether there are ways to handle such additional menu entries.

Regards,

Ulrich

[Vadim Zeitlin]

On Tue, 31 Jan 2023 20:09:40 +0000 Stefan Csomor wrote:

SC> That's great, I need your help here

Hi and sorry for taking so long to answer this.

SC> but when building on the command line using
SC>
SC> configure --without-liblzma --enable-debug --with-zlib=builtin --with-libtiff=builtin --with-osx_cocoa --with-cxx=11 --enable-intl --prefix="$instdir"
SC>
SC> somehow no wxstd-3.3.mo gets created, so the international sample does
SC> not have the default message catalog, when doing a msgfmt de.po -ode.mo
SC> by hand and adding this file as a wxstd-3.3.mo to the de folder of
SC> international sample things are translated properly ...

We indeed don't create message catalogs during the normal build. This is
done by "make install" and when creating the distribution (see
build/tools/release.sh) and can also always be done manually by doing "make
-C locale allmo" (or for individual languages with "xx.mo", of course).

Also, the catalog doesn't need to be called wxstd-3.3.mo, just wxstd.mo
will be found as well.

But, in any case, the fact is that currently the sample only works out of
the box if wxWidgets is installed on the system, either by "make install"
or in some other way (from system package or by "brew install", for
example). I don't know what, if anything, to do about it. In principle, the
sample could look in wxWidgets directory for the message catalogs under
"locale" subdirectory too, but this would require some extra code and
wouldn't be something that is useful for any normal application, so I don't
think it would be a good idea to add it.

Please let me know if you have any better ideas,

[Lauri Nurmi]

Hallo Ulrich,

If you are implying that any changes in the translatable source strings should be immediately reflected to _all_ translations, even in the development branch, master, then I don't know if using this Gettext-style method for wx's own translations is viable at all.

Anteeksi, no offense meant.

No offence taken.

It is just an observation that the message catalogs need an update after such a source change. That is, wxstd.pot needs to be regenerated, so that all other language specific .po files can be updated based on it. Thereafter translators can adjust the translations, whenever they have time to do it.

IMHO ideally there would be no wxstd.pot in git at all. It is always in risk of being outdated, as well as translations based on it. It would be better if all translators regenerated wxstd.pot themselves, which is not terribly hard (as you had noticed). A daily, automatically regenerated wxstd.pot could be made available available somewhere outside of git.

I fully understand your motivation. However, IMHO such changes should be applied to wxstd.pot first, and thereafter to individual .po files. This would make it easier for other translators to update their translations.

Any change in any translatable string would require updating wxstd.pot, which means potentially any commit. And checking the need for wxstd.pot update at each commit is not practical, unless it there is a check for that with pull requests.

Sure, the macOS menu translations are an example of some pretty prominent strings, but in general it is hard to judge when has a PR modified translatable strings significantly enough to require a .pot update and when not.

[utelle]

Hei Lauri,

IMHO ideally there would be no wxstd.pot in git at all. It is always in risk of being outdated, as well as translations based on it. It would be better if all translators regenerated wxstd.pot themselves, which is not terribly hard (as you had noticed). A daily, automatically regenerated wxstd.pot could be made available available somewhere outside of git.

Well, for users of wxWidgets it is important that the message catalogs are maintained regularly and are as up-to-date as is feasible.

IMHO wxstd.pot should be the primary source for updates of the individual message catalogs (.po files). Translators should not regenerate wxstd.pot themselves, even if it is not hard (at least under Linux), they should concentrate on keeping translations in order.

Optimal would be if wxstd.pot could be updated automatically. Although wxstd.pot is in risk of being outdated with every commit, I believe that it will happen only infrequently. So, regenerating wxstd.pot daily unconditionally would not be good, because translators would not know whether translations really need maintenance or not. If possible, wxstd.pot (and .po files) should only be replaced in the repository, if there are actual changes (additions or changes; deletions are not critical).

Maybe it is possible to create a GitHub action to perform this task.

Any change in any translatable string would require updating wxstd.pot, which means potentially any commit. And checking the need for wxstd.pot update at each commit is not practical, unless it there is a check for that with pull requests.

 At the moment I don't know whether the message catalog tools like msgfmt, msgmerge allow to check whether there are changes in a message catalog or not. If that's possible this information could be used to update the affected files in the repository.

Sure, the macOS menu translations are an example of some pretty prominent strings, but in general it is hard to judge when has a PR modified translatable strings significantly enough to require a .pot update and when not.

I fully agree that updating wxstd.pot should usually not be a manual task. However, if a PR is just about adjusting translation strings (as yours was) it is clear that wxstd.pot needs an update.

I will check whether I can come up with a reasonable approach to automate this process.

Regards,

Ulrich

[Vadim Zeitlin]

On Wed, 8 Feb 2023 06:32:54 -0800 (PST) utelle wrote:

u> IMHO *wxstd.pot* should be the primary source for updates of the individual
u> message catalogs (*.po* files).

Yes, but this doesn't necessarily mean that it should be in Git.

u> Optimal would be if *wxstd.pot* could be updated automatically.

Yes.

u> Maybe it is possible to create a GitHub action to perform this task.

It's surely possible, but I think it would be preferable to update it on
the web site.

u> At the moment I don't know whether the message catalog tools like msgfmt,
u> msgmerge allow to check whether there are changes in a message catalog or
u> not. If that's possible this information could be used to update the
u> affected files in the repository.

I certainly hope that msgmerge wouldn't modify the message catalog if
there are no real changes.

u> I will check whether I can come up with a reasonable approach to automate
u> this process.

Thanks in advance! You might also want to have a look at the internat
sample translations, which are never updated at all currently, as discussed
in https://github.com/wxWidgets/wxWidgets/pull/23234 (and 23235).

Finally, if we're changing things here, I wonder if we could get rid of
the "#: filename:line" comments in the files, i.e. use --no-location option
of xgettext. Changes to them create an awful lot of noise, which makes it
totally impossible to review any changes to the translations (granted, in
most cases this is already impossible because I don't understand their
language, but currently I can't even do it for the languages I do know) and
I'm not sure if they're really that useful for the translators -- are they?
If the meaning of the string to translate is so unclear that people have to
check the source code, it would seem that a better solution would be to add
a context for it, just like Lauri did.

[Gunter Königsmann]

Am 8. Februar 2023 16:01:45 MEZ schrieb Vadim Zeitlin <va...@wxwidgets.org>:.

>
>.
>
> I certainly hope that msgmerge wouldn't modify the message catalog if
>there are no real changes.
>

It still updates the timestamp which changes the file when no real changes have occurred.
Never found a way around that.
And it updates the line numbers which can add up to hundreds of changes even if no actual text has changed.

[utelle]

Vadim Zeitlin schrieb am Mittwoch, 8. Februar 2023 um 16:01:50 UTC+1:

u> IMHO *wxstd.pot* should be the primary source for updates of the individual
u> message catalogs (*.po* files).

Yes, but this doesn't necessarily mean that it should be in Git.

Wouldn't it be cumbersome for a developer to be forced to collect the translation files from the website in addition to cloning the git repository? Personally, I would prefer to have all wx files together in the git repository. And if we manage to make the automatic update process clever enough, so that unnecessary "updates" are avoided (when actually nothing relevant has changed), then the number of commits will be rather small.

  u> Maybe it is possible to create a GitHub action to perform this task.

It's surely possible, but I think it would be preferable to update it on
the web site.

Where to put the resulting files can be decided later on, when we have a working process.

 
I certainly hope that msgmerge wouldn't modify the message catalog if
there are no real changes.

One important step would be to use the msgmerge option "--no-location" to remove the source line number information that possibly changes more frequently than the message ids.

 

u> I will check whether I can come up with a reasonable approach to automate
u> this process.

Thanks in advance! You might also want to have a look at the internat
sample translations, which are never updated at all currently, as discussed
in https://github.com/wxWidgets/wxWidgets/pull/23234 (and 23235).

 

I agree that the message catalogs should also be updated automatically.

Finally, if we're changing things here, I wonder if we could get rid of
the "#: filename:line" comments in the files, i.e. use --no-location option
of xgettext.

That should be definitely done. Usually the line number information is of almost no use for the translators.

However, line numbers can be useful sometimes for wx core developers to identify where different message ids were used for the same term.

 

Changes to them create an awful lot of noise, which makes it
totally impossible to review any changes to the translations (granted, in
most cases this is already impossible because I don't understand their
language, but currently I can't even do it for the languages I do know) and
I'm not sure if they're really that useful for the translators -- are they?

No, most of the time they are not useful.

 

If the meaning of the string to translate is so unclear that people have to
check the source code, it would seem that a better solution would be to add
a context for it, just like Lauri did.

Yes, indeed.

Regards,

Ulrich 

[utelle]

Gunter Königsmann schrieb am Mittwoch, 8. Februar 2023 um 16:49:25 UTC+1:

> I certainly hope that msgmerge wouldn't modify the message catalog if
> there are no real changes.

It still updates the timestamp which changes the file when no real changes have occurred.
Never found a way around that.

When comparing the previous .pot file with a potentially updated new .pot file, we then need to ignore the line with the timestamp.

 

And it updates the line numbers which can add up to hundreds of changes even if no actual text has changed.

Since the line numbers can easily change, even when the message ids themselves did not, we should get rid of them. And that is possible by using the option "--no-location".

 

Regards,

Ulrich

[Vadim Zeitlin]

On Wed, 8 Feb 2023 15:38:55 -0800 (PST) utelle wrote:

u> Wouldn't it be cumbersome for a developer to be forced to collect the
u> translation files from the website in addition to cloning the git
u> repository? Personally, I would prefer to have all wx files together in the
u> git repository. And if we manage to make the automatic update process
u> clever enough, so that unnecessary "updates" are avoided (when actually
u> nothing relevant has changed), then the number of commits will be rather
u> small.

I don't think an extra curl is such a big deal but, again, this is a
question that we should probably ask the translators.

u> However, line numbers can be useful sometimes for wx core developers to
u> identify where different message ids were used for the same term.

FWIW I think I've never used them myself.

[Lauri Nurmi]

Gunter Königsmann kirjoitti 8.2.2023 klo 17:49:
> Am 8. Februar 2023 16:01:45 MEZ schrieb Vadim Zeitlin <va...@wxwidgets.org>:.

>> I certainly hope that msgmerge wouldn't modify the message catalog if
>> there are no real changes.
>>
> It still updates the timestamp which changes the file when no real changes have occurred.
> Never found a way around that.

One can argue it should not update the timestamp in that case, but  an
equally valid argument is that it should, for the purpose of documenting
what .pot version the .po was merged against.

Ignoring this change should be pretty trivial if you are already calling
msgmerge from a shell script. Something like:

[ $(git diff mylang.po | tail -n +5 | grep -Ec '^\+') == 1 ] && git
checkout mylang.po

[Stefan Csomor]

Hi Vadim

 

SC> configure  --without-liblzma --enable-debug --with-zlib=builtin --with-libtiff=builtin --with-osx_cocoa --with-cxx=11 --enable-intl --prefix="$instdir"

SC> 

SC> somehow no wxstd-3.3.mo gets created, so the international sample does

SC> not have the default message catalog, when doing a msgfmt de.po -ode.mo

SC> by hand and adding this file as a wxstd-3.3.mo to the de folder of

SC> international sample things are translated properly ...

 

>We indeed don't create message catalogs during the normal build. This is

>done by "make install" and when creating the distribution (see

>build/tools/release.sh) and can also always be done manually by doing "make

>-C locale allmo" (or for individual languages with "xx.mo", of course).

 

Thanks, I thought that it was part of “make install” even when I have a prefix given, but apparently it is not

 

>But, in any case, the fact is that currently the sample only works out of

>the box if wxWidgets is installed on the system, either by "make install"

>or in some other way (from system package or by "brew install", for example). 

 

That’s what I thought too, but apparently the –prefix made “make install” interfered with this ?

 

Thanks,

 

Stefan 

 

 

 

[Vadim Zeitlin]

On Thu, 9 Feb 2023 14:59:37 +0000 Stefan Csomor wrote:

SC> That’s what I thought too, but apparently the –prefix made “make
SC> install” interfered with this ?

Actually I was wrong about "make install" installing the message catalogs.
Or, rather, it does do it, but only if they already exist, i.e. if they had
been already compiled before, e.g. by "make -C locale allmo".

I don't really see any reason for it to behave like this, to be honest.
AFAIK all packages compile their translations as part of their "make
install" and don't require you to do it separately. I guess we might have
wanted to let "make install" work without requiring to install GNU gettext
tools, but even if it was worth doing it in the past, it surely shouldn't
be a big problem to install them now.

Anyhow, I'm not going to do anything about it right now, but I've created
https://github.com/wxWidgets/wxWidgets/issues/23244 and might change this
later if there is sufficient interest in (and no problems with) doing it.

Regards,

[Lauri Nurmi]

utelle kirjoitti 9.2.2023 klo 1:38:
> Vadim Zeitlin schrieb am Mittwoch, 8. Februar 2023 um 16:01:50 UTC+1:
> u> IMHO *wxstd.pot* should be the primary source for updates of the
> individual
> u> message catalogs (*.po* files).
>
> Yes, but this doesn't necessarily mean that it should be in Git.
>
> Wouldn't it be cumbersome for a developer to be forced to collect the
> translation files from the website in addition to cloning the git
> repository?

But would it? Downloading one file from a well known location. And how
often does one need to do that anyway.

Between 2018 and 2022 (5 full years) there were 74 commits to
locale/*.po files. There are 46 .po files. That means 0.32 commits per
file per year. In other words, a translation is modified once every 3
years on average. Even if a more frequently updating wxstd.pot activates
translators, I would be surprised if the average per-file update rate
rose above 1 commit per year. The potential cumbersomeness is not going
to be a day-to-day annoyance to anyone.