Translations on Mac (was Translations)
René J.V. Bertin
rjvbertin at gmail.com
Thu Sep 7 13:02:05 UTC 2017
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.
>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
>
>
>
>On 07/09/2017 08:11, Kåre Särs wrote:
>> Hi,
>>
>> (even tho I'm not Hannah :)
>> On torsdag 7 september 2017 kl. 00:39:59 EEST Robert Lancaster wrote:
>>> 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/
>>
>> Then the search path would be something like:
>> "<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
>>
>
>
More information about the Kde-frameworks-devel
mailing list