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

List:       kde-i18n-doc
Subject:    Re: KGeography needs your help
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2005-08-10 3:52:01
Message-ID: 200508100552.04119.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Nicolas Goutte :]
> I suppose that you will have to branch kdelibs to show the
> functionality (I am not sure if you should show it on KDE 3 or on KDE4,
> both will probably have their advanatges and inconveniences.)

That is an interesting question, especially due to fact that I cannot get 
trunk code to work properly (a lot of crashes, desktop doesn't work at 
all) :) But still, with trunk I can run separate programs, which I think 
is enough to show what scripting does.

> The change really seem to have a huge impact, even if the change of the
> interface is minimal. Therefore I doubt that it will enter kdelibs
> directly.

Currently basic i18n is like this:

QString i18n(const char* text)
{
  register KLocale *instance = KGlobal::locale();
  if (instance)
    // Return translation
    return instance->translate(text);

  // Just return original text
  return QString::fromUtf8(text);
}

With scripting i18n becomes a friendly wrapper for KI18n class:

KI18n i18n(const char* text)
{
  return KI18n(text);
}

And the KI18n class constructor that does the job of old i18n:

KI18n::KI18n(const char* text) : m_script(false), m_priv(0)
{
  register KLocale *instance = KGlobal::locale();
  if (instance)
  {
    // Get msgstr into underlying Qstring
    QString::operator=(instance->translate(text));

    if (instance->useTranScript()) // Are we using scripting at all?
    {
      m_script = true; // That boolean from above.
      m_priv = new PrivateSection; // That internal stuff from above.
      ... // And rest of initialization for scripting.
    }
  }
  else
    // Put text into underlying Qstring
    QString::operator=(QString::fromUtf8(text));
}

So, only data KI18n has are:

- 1 boolean, saying if scripting is enabled or disabled
- 1 pointer for internal data (not initialized if scripting is disabled)
- 1 QString holding the translation

KI18n also has own arg() methods of same form as those in QString, so that 
we can catch arguments. E.g. like this:

KI18n& KI18n::arg(const QString& a, int fieldWidth)
{
  QString::operator=(QString::arg(a, fieldWidth));
  if (m_script) m_priv->somethingWithArgument(...);
  return *this;
}

If we could also make sure that scripting engine (whatever it is) gets 
dynamically loaded only if given language requests it (as Stephan 
suggested), would this still constitute too big change or overhead for the 
core?

> As for kde-core-devel, yes, it will be probably a needed discussion
> too. The question is more if you should do the discussion with some
> code in SVN or if you should do the discussion with just a "white
> paper", like now in this thread.

I very much would like to approach kde-core-devel with the code, but I need 
some help with SVN. I've been going again though chapter on branching in 
SVN Book, but there they just assume that whole directory tree is 
branched, and then periodically merged from trunk. In this case, this 
seems excessive, as I have modified only klocale.h and klocale.cpp and 
added one .h/.cpp pair (and mentioned them in Makefile.am) in 
kdelibs/kdecore. What should I do?

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

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