[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Translations in Kube, do we need ki18n?
From:       Christian Mollekopf <chrigi_1 () fastmail ! fm>
Date:       2017-07-19 16:51:18
Message-ID: 1500483078.270746.1046108128.71F3DF67 () webmail ! messagingengine ! com
[Download RAW message or body]

Thank you very much for the detailed response, that explains things
nicely.
We'll try the qsTr route then.

Also thanks Kevin for the extra input =)

Cheers,
Christian

On Wed, Jul 19, 2017, at 12:43 PM, Harald Sitter wrote:
> Yo
> 
> On Tue, Jul 18, 2017 at 9:18 PM, Christian Mollekopf
> <chrigi_1@fastmail.fm> wrote:
> > Hi,
> >
> > I'm going to start making the Kube codebase translatable soon, but I
> > have one question.
> >
> > Do we really need ki18n and if so, why?
> 
> I am no expert on the matter but technically you do not need to use
> ki18n. e.g. various frameworks are qt-only. Also, kirigami and
> gcompris are AFAIK qsTr() only (i.e. no ki18n qml either). To get this
> going you'll need to make sure that your Messages.sh extract a `_qt`
> suffixed pot (e.g. foobar_qt.pot), in  cmake generate a loder
> (ecm_create_qm_loader) and install translations using the right macro
> (ecm_install_po_files_as_qm).
> Best hold on to what kirigami does I guess.
> 
> > I'd prefer QObject::tr for dependency reasons. The QML variant (which we
> > need), is in KDeclarative, which depends on KIO, which is a no-go for
> > us, but I can fix that by implementing the same wrapper that
> > KDeclarative has. However, I at least would like to understand what for
> > if it is indeed necessary, and couldn't figure that out so far.
> >
> > Could somebody help me understand or let me know if it is ok to use
> > QObject::tr instead, and in what limitations that would result?
> 
> Again, no expert, but unless you find that you want a feature of ki18n
> or encounter the limitations of tr() there is no real need to use
> ki18n. The biggest advantage of ki18n to me is semantic markup [1]
> allowing you to tag strings with a specific UI usage marker and
> instead of writing richtext relying on common markup tags such as
> `<filename>` to employ standard styling. It also has more accessible
> and/or powerful catalog loading I seem to recall. But if you find that
> you do not need much more than strings and plural strings and maybe
> strings with numbers, Qt's translation system should get the job done
> just as well.
> 
> [1] https://api.kde.org/frameworks/ki18n/html/prg_guide.html#kuit_markup
> 
> HS
[prev in list] [next in list] [prev in thread] [next in thread]