Translations on Mac (was Translations)
Ben Cooksley
bcooksley at kde.org
Sat Sep 9 19:22:40 UTC 2017
On Sat, Sep 9, 2017 at 9:18 AM, Jasem Mutlaq <mutlaqja at ikarustech.com> wrote:
> 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
>
>
> On Thu, Sep 7, 2017 at 4:02 PM, René J.V. Bertin <rjvbertin at gmail.com>
> wrote:
>>
>> 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
>> >>
>> >
>> >
>>
>
>
>
> --
> Best Regards,
> Jasem Mutlaq
>
More information about the Kde-frameworks-devel
mailing list