Translations on Mac (was Translations)

Discussion:

Hannah von Reth

2017-09-07 12:37:56 UTC

Permalink

Hm this looks indeed like we need to fix ecm.

Here is what we did for Windows

https://github.com/KDE/extra-cmake-modules/blob/master/kde-modules/KDEInstallDirs.cmake#L520

I'll include the mac mailing list and the frameworks maling list.

Hannah

Hi,
(even tho I'm not Hannah :)

Hi Hannah,
Jasem was telling me today about a new translations feature that was
implemented. He said there might be problems on Macs and Windows but that
you are working on it. I tried his instructions and got partially there.
I went to the directory I was building kstars. I used make
fetch-translations and it acquired the po files. Then I did make and it
made the mo files. Then I did make install and it put them into a
subfolder called /share/locale. But it doesnât show up in the program.

KI18n searches <QStandardPaths::GenericDataLocation>/locale/ for the
translation files. So on Windows one of the search paths is <app dir>/data/
locale/
"<app dir>/data/locale/<lang code>/LC_MESSAGES/<catalog>.mo"

Does this feature need to look in the /usr/share/locale directory for the
translation files or is it a relative path? A big problem with that is
that on MacOS, the /usr/share directory is not writeable except by the
system. Is there a way to change where it looks for the files, like a
preference? Or would you need to hard-code locations? A good place to
look for them would be inside the app bundle like
Kstars.app/Contents/Resources/locale or in ~/Library/Application
Support/kstars/locale.

I would assume that the this means "/Library/Application Support/locale/..."
in the application bundle. (Note: I don't have a Mac to check with...)
/KÃ¥re

René J.V. Bertin

2017-09-07 13:02:05 UTC

Permalink

On Thursday September 07 2017 14:37:56 Hannah von Reth wrote:

What ECM really ought to have is a link to QStandardPaths which is the source of all the evil mentioned below. In the simplest approach it could be set up when being configured, querying the qtpaths utility for the writable standard locations, but it could also include a simpler version of that utility (which can receive a program name argument so that it can return the exact correct app-specific locations).

NB: the only thing to look out for is the writable ApplicationsLocation which is likely (used) to be /Applications on Mac ... which has a whole different role on Mac than that location has on Linux.

The standard location for GenericDataLocation (that's where the locale directory is expected?) on Mac:
~/Library/Application Support:/Library/Application Support

One big request: don't hardcode any Mac changes. I'm following the complementary approach in my KF5 ports for MacPorts, patching QStandardPaths so it returns compatible ("standard") locations, so the .mo files in my $prefix/share/locale work as expected.

R.

Post by Hannah von Reth
Hm this looks indeed like we need to fix ecm.
Here is what we did for Windows

https://github.com/KDE/extra-cmake-modules/blob/master/kde-modules/KDEInstallDirs.cmake#L520

I'll include the mac mailing list and the frameworks maling list.
Hannah

Hi,
(even tho I'm not Hannah :)

I would assume that the this means "/Library/Application Support/locale/..."
in the application bundle. (Note: I don't have a Mac to check with...)
/Kåre

Ben Cooksley

2017-09-09 19:22:40 UTC

Permalink

Could it be possible to also look for translations relative the current
binary? Like on Windows using Craft translations are stored in
bin/data/locale, can a similar structure be used in MacOS? Does this require
a change in KF5 or ECM cmake scripts?

The only way to my knowledge of doing this on MacOS is to include them
within the .app bundle.
This is a limitation imposed by Qt and applies to all resources which
are accessed using QStandardPaths.

Regards,
Ben

Regards,
Jasem

Post by RenÃ© J.V. Bertin
What ECM really ought to have is a link to QStandardPaths which is the
source of all the evil mentioned below. In the simplest approach it could be
set up when being configured, querying the qtpaths utility for the writable
standard locations, but it could also include a simpler version of that
utility (which can receive a program name argument so that it can return the
exact correct app-specific locations).
NB: the only thing to look out for is the writable ApplicationsLocation
which is likely (used) to be /Applications on Mac ... which has a whole
different role on Mac than that location has on Linux.
The standard location for GenericDataLocation (that's where the locale
~/Library/Application Support:/Library/Application Support
One big request: don't hardcode any Mac changes. I'm following the
complementary approach in my KF5 ports for MacPorts, patching QStandardPaths
so it returns compatible ("standard") locations, so the .mo files in my
$prefix/share/locale work as expected.
R.

Post by Hannah von Reth
Hm this looks indeed like we need to fix ecm.
Here is what we did for Windows

https://github.com/KDE/extra-cmake-modules/blob/master/kde-modules/KDEInstallDirs.cmake#L520

I'll include the mac mailing list and the frameworks maling list.
Hannah

Hi,
(even tho I'm not Hannah :)

I would assume that the this means "/Library/Application
Support/locale/..."
in the application bundle. (Note: I don't have a Mac to check with...)
/Kåre

--
Best Regards,
Jasem Mutlaq

René J.V. Bertin

2017-09-09 20:00:09 UTC

Permalink

Post by Ben Cooksley
The only way to my knowledge of doing this on MacOS is to include them
within the .app bundle.
This is a limitation imposed by Qt and applies to all resources which
are accessed using QStandardPaths.

Can you show which QSP locations point into the application bundle?!

Here's the output from stock qtdiag 5.9.1 for Mac:

Standard paths [*...* denote writable entry]:
DesktopLocation: "Desktop" */Users/RB/Desktop*
DocumentsLocation: "Documents" */Users/RB/Documents*
FontsLocation: "Fonts" */Users/RB/Library/Fonts* /Library/Fonts /System/Library/Fonts
ApplicationsLocation: "Applications" */Users/RB/Applications* /Applications
MusicLocation: "Music" */Users/RB/Music*
MoviesLocation: "Movies" */Users/RB/Movies*
PicturesLocation: "Pictures" */Users/RB/Pictures*
TempLocation: "Temporary Items" */var/folders/x/y/T*
HomeLocation: "Home" */Users/RB*
AppLocalDataLocation: "Application Support" */Users/RB/Library/Application Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag /usr/local/qt/5b/5.9.1/clang_64/bin
CacheLocation: "Caches" */Users/RB/Library/Caches/QtProject/qtdiag* /Library/Caches/QtProject/qtdiag
GenericDataLocation: "Application Support" */Users/RB/Library/Application Support* /Library/Application Support
RuntimeLocation: "Application Support" */Users/RB/Library/Application Support*
ConfigLocation: "Preferences" */Users/RB/Library/Preferences*
DownloadLocation: "Downloads" */Users/RB/Downloads*
GenericCacheLocation: "Caches" */Users/RB/Library/Caches* /Library/Caches /System/Library/Caches
GenericConfigLocation: "Preferences" */Users/RB/Library/Preferences*
AppDataLocation: "Application Support" */Users/RB/Library/Application Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag /usr/local/qt/5b/5.9.1/clang_64/bin
AppConfigLocation: "Preferences" */Users/RB/Library/Preferences/QtProject/qtdiag*

Putting everything in the app bundle is a condition imposed by Apple's app store rules, not by Qt and no QSP locations point into the app bundle.
There's a very simple reason for that: app bundles are relocatable, and QSP locations are all returned as absolute paths. A future Qt version will have a modified QSP::findExecutable() which can provide the path to the bundle exec of any foo.app known by LaunchServices but that's the only case I know of where QSP will return a location inside an app bundle.

Qt does have a deployment utility to "bundle up" an application and I presume that will work with their own translation files. AFAIK those used by KI18n are different. I suppose the people behind the Kate, digiKam and KDevelop builds for Mac know better (than I do) how they bundle the translation files and get KI18n to find them inside the app bundle.

Also do not forget that not all KF5 applications are built as app bundles: many helper applications and daemons are built as regular executables. Some of them can post GUIs or generate other forms of translatable output.

This is what an extended QStandardPaths with support for XDG-compliant locations could output - it is still my intention to make another attempt to upstream such a patch:

Standard paths [*...* denote writable entry]:
- QStandardPaths is in XDG/Freedesktop compliant mode -
DesktopLocation: "Desktop" = */Users/RB/Desktop*
DocumentsLocation: "Documents" = */Users/RB/Documents*
FontsLocation: "Fonts" = */Users/RB/Library/Fonts* /Library/Fonts /System/Library/Fonts
ApplicationsLocation: "Applications" = */Users/RB/.local/share/applications* /Users/RB/Applications /opt/local/share/applications /Applications
MusicLocation: "Music" = */Users/RB/Music*
MoviesLocation: "Movies" = */Users/RB/Movies*
PicturesLocation: "Pictures" = */Users/RB/Pictures*
TempLocation: "Temporary Items" = */var/folders/X/Y/T*
HomeLocation: "Home" = */Users/RB*
DataLocation: "Application Support" = */Users/RB/.local/share/QtProject/qtdiag* /Users/RB/Library/Application Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
AppLocalDataLocation: "Application Support" = */Users/RB/.local/share/QtProject/qtdiag* /Users/RB/Library/Application Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
CacheLocation: "Caches" = */Users/RB/.cache/QtProject/qtdiag* /Users/RB/Library/Caches/QtProject/qtdiag /Users/RB/.cache /Library/Caches/QtProject/qtdiag
GenericDataLocation: "share" = */Users/RB/.local/share* /Users/RB/Library/Application Support /opt/local/share /Library/Application Support
RuntimeLocation: "runtime-bertin" = */var/folders/X/Y/T/runtime-bertin* /Users/RB/Library/Application Support
ConfigLocation: ".config" = */Users/RB/.config* /Users/RB/Library/Preferences /opt/local/etc/xdg
DownloadLocation: "Downloads" = */Users/RB/Downloads*
GenericCacheLocation: ".cache" = */Users/RB/.cache* /Users/RB/Library/Caches /Users/RB/.cache /Library/Caches /System/Library/Caches
GenericConfigLocation: ".config" = */Users/RB/.config* /Users/RB/Library/Preferences /opt/local/etc/xdg
AppDataLocation: "Application Support" = */Users/RB/.local/share/QtProject/qtdiag* /Users/RB/Library/Application Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
AppConfigLocation: "Preferences" = */Users/RB/Library/Preferences/QtProject/qtdiag*

Ben Cooksley

2017-09-09 20:06:34 UTC

Permalink

Post by RenÃ© J.V. Bertin

Can you show which QSP locations point into the application bundle?!

Please see http://doc.qt.io/qt-5/qstandardpaths.html

The paths in question are any where <APPDIR> is referenced.
Quoting the Qt documentation here: "<APPDIR> is the directory
containing the application executable."

This means DataLocation, AppDataLocation and AppLocalDataLocation will
all look at locations inside the bundle if possible.

If my reading of it is correct, if binaries are installed to
$prefix/bin/ then the correct location for Qt to find them would be
$prefix/Resources on MacOS.

I've no idea if the code path for <APPDIR> to work is only switched on
if it's built inside a bundle though.

Cheers,
Ben

Post by RenÃ© J.V. Bertin
DesktopLocation: "Desktop" */Users/RB/Desktop*
DocumentsLocation: "Documents" */Users/RB/Documents*
FontsLocation: "Fonts" */Users/RB/Library/Fonts* /Library/Fonts /System/Library/Fonts
ApplicationsLocation: "Applications" */Users/RB/Applications* /Applications
MusicLocation: "Music" */Users/RB/Music*
MoviesLocation: "Movies" */Users/RB/Movies*
PicturesLocation: "Pictures" */Users/RB/Pictures*
TempLocation: "Temporary Items" */var/folders/x/y/T*
HomeLocation: "Home" */Users/RB*
AppLocalDataLocation: "Application Support" */Users/RB/Library/Application Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag /usr/local/qt/5b/5.9.1/clang_64/bin
CacheLocation: "Caches" */Users/RB/Library/Caches/QtProject/qtdiag* /Library/Caches/QtProject/qtdiag
GenericDataLocation: "Application Support" */Users/RB/Library/Application Support* /Library/Application Support
RuntimeLocation: "Application Support" */Users/RB/Library/Application Support*
ConfigLocation: "Preferences" */Users/RB/Library/Preferences*
DownloadLocation: "Downloads" */Users/RB/Downloads*
GenericCacheLocation: "Caches" */Users/RB/Library/Caches* /Library/Caches /System/Library/Caches
GenericConfigLocation: "Preferences" */Users/RB/Library/Preferences*
AppDataLocation: "Application Support" */Users/RB/Library/Application Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag /usr/local/qt/5b/5.9.1/clang_64/bin
AppConfigLocation: "Preferences" */Users/RB/Library/Preferences/QtProject/qtdiag*
Putting everything in the app bundle is a condition imposed by Apple's app store rules, not by Qt and no QSP locations point into the app bundle.
There's a very simple reason for that: app bundles are relocatable, and QSP locations are all returned as absolute paths. A future Qt version will have a modified QSP::findExecutable() which can provide the path to the bundle exec of any foo.app known by LaunchServices but that's the only case I know of where QSP will return a location inside an app bundle.
Qt does have a deployment utility to "bundle up" an application and I presume that will work with their own translation files. AFAIK those used by KI18n are different. I suppose the people behind the Kate, digiKam and KDevelop builds for Mac know better (than I do) how they bundle the translation files and get KI18n to find them inside the app bundle.
Also do not forget that not all KF5 applications are built as app bundles: many helper applications and daemons are built as regular executables. Some of them can post GUIs or generate other forms of translatable output.
- QStandardPaths is in XDG/Freedesktop compliant mode -
DesktopLocation: "Desktop" = */Users/RB/Desktop*
DocumentsLocation: "Documents" = */Users/RB/Documents*
FontsLocation: "Fonts" = */Users/RB/Library/Fonts* /Library/Fonts /System/Library/Fonts
ApplicationsLocation: "Applications" = */Users/RB/.local/share/applications* /Users/RB/Applications /opt/local/share/applications /Applications
MusicLocation: "Music" = */Users/RB/Music*
MoviesLocation: "Movies" = */Users/RB/Movies*
PicturesLocation: "Pictures" = */Users/RB/Pictures*
TempLocation: "Temporary Items" = */var/folders/X/Y/T*
HomeLocation: "Home" = */Users/RB*
DataLocation: "Application Support" = */Users/RB/.local/share/QtProject/qtdiag* /Users/RB/Library/Application Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
AppLocalDataLocation: "Application Support" = */Users/RB/.local/share/QtProject/qtdiag* /Users/RB/Library/Application Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
CacheLocation: "Caches" = */Users/RB/.cache/QtProject/qtdiag* /Users/RB/Library/Caches/QtProject/qtdiag /Users/RB/.cache /Library/Caches/QtProject/qtdiag
GenericDataLocation: "share" = */Users/RB/.local/share* /Users/RB/Library/Application Support /opt/local/share /Library/Application Support
RuntimeLocation: "runtime-bertin" = */var/folders/X/Y/T/runtime-bertin* /Users/RB/Library/Application Support
ConfigLocation: ".config" = */Users/RB/.config* /Users/RB/Library/Preferences /opt/local/etc/xdg
DownloadLocation: "Downloads" = */Users/RB/Downloads*
GenericCacheLocation: ".cache" = */Users/RB/.cache* /Users/RB/Library/Caches /Users/RB/.cache /Library/Caches /System/Library/Caches
GenericConfigLocation: ".config" = */Users/RB/.config* /Users/RB/Library/Preferences /opt/local/etc/xdg
AppDataLocation: "Application Support" = */Users/RB/.local/share/QtProject/qtdiag* /Users/RB/Library/Application Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
AppConfigLocation: "Preferences" = */Users/RB/Library/Preferences/QtProject/qtdiag*

René J.V. Bertin

2017-09-09 20:44:35 UTC

Permalink

Post by Ben Cooksley
Please see http://doc.qt.io/qt-5/qstandardpaths.html
The paths in question are any where <APPDIR> is referenced.
Quoting the Qt documentation here: "<APPDIR> is the directory
containing the application executable."
This means DataLocation, AppDataLocation and AppLocalDataLocation will
all look at locations inside the bundle if possible.

Hmm, it's indeed possible that those locations are appended to the list of locations I provided *IF* the application was built as a bundle. I'd have to build qtdiag or qtpaths that way to confirm (or look at the source...)

Still, those are just additional options where code can look if no hit is obtained elsewhere. It's never the writable location, so my idea of using qtpaths or a similar dedicated utility to query the QSP writable locations isn't going to work to determine install locations inside an app bundle.

It would fit in with suggestions I made earlier to implement something like a APPLE_STANDALONE_APPBUNDLE CMake option to control whether (or not) Mac builds should lead to a standalone app bundle (= one with everything inside the bundle).

R.

René J.V. Bertin

2017-09-15 10:47:13 UTC

Permalink

On Saturday September 09 2017 00:18:09 Jasem Mutlaq wrote:

I'd say "anything is possible", including reproducing an "XDG-compliant" tree structure inside a Mac app bundle or a MSWin install directory. For app bundles it's not uncommon in other projects, AFAIK, configuring with something like

--prefix=/path/to/Foo.app/Contents --bindir=$prefix/MacOS

Of course that means you end up with a non-relocatable app bundle, or a MSWin installer that can only target a single install location.

If craft knows how to use relative install locations, and the various KF5 work with that, great. But it'd have to be done in a way that's compatible with QStandardPaths.

R.

Syed Zayyan

2017-10-03 07:44:57 UTC

Permalink

i wanna fuck you plz

Post by Hannah von Reth
Hm this looks indeed like we need to fix ecm.
Here is what we did for Windows

https://github.com/KDE/extra-cmake-modules/blob/master/kde-

modules/KDEInstallDirs.cmake#L520
I'll include the mac mailing list and the frameworks maling list.
Hannah

Hi,
(even tho I'm not Hannah :)

Hi Hannah,
Jasem was telling me today about a new translations feature that was
implemented. He said there might be problems on Macs and Windows but

that

you are working on it. I tried his instructions and got partially

there.

I went to the directory I was building kstars. I used make
fetch-translations and it acquired the po files. Then I did make and it
made the mo files. Then I did make install and it put them into a
subfolder called /share/locale. But it doesnât show up in the program.

KI18n searches <QStandardPaths::GenericDataLocation>/locale/ for the
translation files. So on Windows one of the search paths is <app

dir>/data/

locale/
"<app dir>/data/locale/<lang code>/LC_MESSAGES/<catalog>.mo"

Does this feature need to look in the /usr/share/locale directory for

the

translation files or is it a relative path? A big problem with that is
that on MacOS, the /usr/share directory is not writeable except by the
system. Is there a way to change where it looks for the files, like a
preference? Or would you need to hard-code locations? A good place to
look for them would be inside the app bundle like
Kstars.app/Contents/Resources/locale or in ~/Library/Application
Support/kstars/locale.

I would assume that the this means "/Library/Application

Support/locale/..."

in the application bundle. (Note: I don't have a Mac to check with...)
/KÃ¥re