> [: Sebastian Kügler :]
> Putting KLocalizedString::insertCatalog in is good enough, mark it
> DEPRECATED so we get warned that porting work is coming up.
The way I see it, there are no more KLocalizedString::insertCatalog() calls
anywhere :) All newly incoming code for porting will have the olde
> [: Albert Astals Cid :]
> to make it more obvious maybe it should be KI18N_TRANSLATION_DOMAIN ?
Well possibly, but to me it looks redundant: "translation domain" is already
Gettext-specific terminology, and it would be bizarre to use more than one
Gettext-based system in the same piece of code s
On Monday 05 August 2013 20:57:33 Chusslove Illich wrote:
> My notion of source compatibility was that it builds and works, not only
> that it builds :) Is there really a point of leaving in dummy methods just
> so that the build can proceed, even if they do nothing? As I mentioned, my
> intention
On Monday 05 August 2013 20:57:33 Chusslove Illich wrote:
> My notion of source compatibility was that it builds and works, not only
> that it builds :) Is there really a point of leaving in dummy methods just
> so that the build can proceed, even if they do nothing? As I mentioned, my
> intention
On Monday 05 August 2013 22:35:08 Albert Astals Cid wrote:
> El Dilluns, 5 d'agost de 2013, a les 22:14:07, Chusslove Illich va escriure:
> > > [: Albert Astals Cid :]
> > > How would that
> > >
> > > set(TRANSLATION_DOMAIN "foobar")
> > >
> > > help you knowing if you want a i18n() or a tr()
El Dilluns, 5 d'agost de 2013, a les 22:14:07, Chusslove Illich va escriure:
> > [: Albert Astals Cid :]
> > How would that
> >
> > set(TRANSLATION_DOMAIN "foobar")
> >
> > help you knowing if you want a i18n() or a tr() based system?
>
> It would automatically use i18n() if TRANSLATION_DOMA
> [: Albert Astals Cid :]
> How would that
> set(TRANSLATION_DOMAIN "foobar")
> help you knowing if you want a i18n() or a tr() based system?
It would automatically use i18n() if TRANSLATION_DOMAIN is defined :)
Because it would have no purpose with tr()-based code.
>> [: Chusslove Illich :]
El Dilluns, 5 d'agost de 2013, a les 21:10:15, Chusslove Illich va escriure:
> >>> [: Albert Astals Cid :]
> >>> If I can't convice you so that we write software that primarily works
> >>> for ourselves can I at least convince you to make so that
> >>> kconfig_compiler forces you to pass a command
Hi Chusslove,
On Monday, August 05, 2013 20:57:33 Chusslove Illich wrote:
> > [: Sebastian Kügler :]
> > I'm not really happy about this patch, since it introduces build breakage.
> > [...] Also, a reminder: Please build plasma-framework[master] and kde-
> > workspace[frameworks-scratch] if you do
>>> [: Albert Astals Cid :]
>>> If I can't convice you so that we write software that primarily works
>>> for ourselves can I at least convince you to make so that
>>> kconfig_compiler forces you to pass a command line parameter saying
>>> which i18n model you follow and fails otherwise so people h
> [: Sebastian Kügler :]
> I'm not really happy about this patch, since it introduces build breakage.
> [...] Also, a reminder: Please build plasma-framework[master] and kde-
> workspace[frameworks-scratch] if you do changes, to make sure that no one
> else has to sift through mailinglist threads [
On Monday 05 August 2013 16:19:07 Sebastian Kügler wrote:
> Hi Chusslove,
>
> On Friday, August 02, 2013 12:00:50 Chusslove Illich wrote:
> > > [: David Faure :]
> > > There's no way to keep the [insertCatalog] method for source
> > > compatibility
> > > and implement it somehow on top of the new
El Dilluns, 5 d'agost de 2013, a les 07:18:29, Kevin Ottens va escriure:
> On Saturday 03 August 2013 16:29:27 Albert Astals Cid wrote:
> > El Divendres, 2 d'agost de 2013, a les 20:49:02, Kevin Ottens va escriure:
> > > On Friday 02 August 2013 19:15:50 Albert Astals Cid wrote:
> > > > El Divendre
Hi Chusslove,
On Friday, August 02, 2013 12:00:50 Chusslove Illich wrote:
> > [: David Faure :]
> > There's no way to keep the [insertCatalog] method for source compatibility
> > and implement it somehow on top of the new solution?
>
> The problem is that insertCatalog no longer has a meaning. It
On Saturday 03 August 2013 16:29:27 Albert Astals Cid wrote:
> El Divendres, 2 d'agost de 2013, a les 20:49:02, Kevin Ottens va escriure:
> > On Friday 02 August 2013 19:15:50 Albert Astals Cid wrote:
> > > El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va
escriure:
> > > > Well, th
El Divendres, 2 d'agost de 2013, a les 20:49:02, Kevin Ottens va escriure:
> On Friday 02 August 2013 19:15:50 Albert Astals Cid wrote:
> > El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure:
> > > Well, the default has to make sense to someone who just makes a Qt
> > > appli
On Friday 02 August 2013 19:15:50 Albert Astals Cid wrote:
> El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure:
> > Well, the default has to make sense to someone who just makes a Qt
> > application and use KConfig as an extra. If kconfig_compiler generates by
> > default so
El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure:
> On Thursday 01 August 2013 22:03:36 Albert Astals Cid wrote:
> > El Dijous, 1 d'agost de 2013, a les 12:54:07, Kevin Ottens va escriure:
> > > Hello,
> > >
> > > On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote:
> [: David Faure :]
> There's no way to keep the [insertCatalog] method for source compatibility
> and implement it somehow on top of the new solution?
The problem is that insertCatalog no longer has a meaning. Its purpose was
to add more translation catalogs into the current process, and all of t
On Wednesday 31 July 2013 19:58:52 Chusslove Illich wrote:
> /**
> - * Inserts the catalog in the main locale object if it exists.
> - * Otherwise the catalog name is stored and added once the main locale
> gets created - * @since 4.6
> - * @deprecated since 5.0, use KLocalized
On Thursday 01 August 2013 22:03:36 Albert Astals Cid wrote:
> El Dijous, 1 d'agost de 2013, a les 12:54:07, Kevin Ottens va escriure:
> > Hello,
> >
> > On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote:
> > > > [: Kevin Ottens :]
> > > > What's needed for kconfig_compiler? Because curre
El Dijous, 1 d'agost de 2013, a les 12:54:07, Kevin Ottens va escriure:
> Hello,
>
> On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote:
> > > [: Kevin Ottens :]
> > > What's needed for kconfig_compiler? Because currently kconfig isn't
> > > supposed to depend on ki18n at all.
> >
> > It
Hello,
On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote:
> > [: Kevin Ottens :]
> > What's needed for kconfig_compiler? Because currently kconfig isn't
> > supposed to depend on ki18n at all.
>
> It does generate translation calls as necessary, and currently it accepts an
> option (from
> [: Kevin Ottens :]
> What's needed for kconfig_compiler? Because currently kconfig isn't
> supposed to depend on ki18n at all.
It does generate translation calls as necessary, and currently it accepts an
option (from .kcfgc file) whether to generate tr or i18n calls. So another
option to specify
Hello,
On Wednesday 31 July 2013 19:58:52 Chusslove Illich wrote:
> Ki18n modifications for KF5 are now roughly completed, in the sense that it
> behaves according to the new spec, the frameworks branch compiles, and the
> existing unit tests pass (those still applicable). Things left to do
> incl
Ki18n modifications for KF5 are now roughly completed, in the sense that it
behaves according to the new spec, the frameworks branch compiles, and the
existing unit tests pass (those still applicable). Things left to do
include:
* Update KDE5PORTING.html (the few salient points).
* Update kcon
26 matches
Mail list logo
