KDE4 proposal: Paths in i18n strings

[Jarosław Staniek]

> We have two distinct problems to address here.

Thanks for your analysis. In fact, yes, API consistency is important to all of 
us, users of the stuff for next years. 

> I don't think marking output by placeholders is the best idea. Even if we
> could hide that from translators, it would still remain something
> out-of-the-world for programmers to learn, and they would have to rely on
> repository infrastructure (what if someone develops for KDE outside of our
> repository?). Outside of code, it is prefferable to have normal Gettext
> operation cycle.

1. We depend on kde-xgettext anyway, I think it's true for projects outside of 
KDE SVN as well.
2. %N is not recogized by gettext as something special, is it?

If my points are true, I still belive %'N' is usable, short, well defined, and 
makes the source code cleaner, and extendable (avoids BIC problems if we add 
another special case one day). 
Moreover the whole gettext-based i18n is a magic after all...


BTW, I had another idea, somewhat consistent with kDebug, but this probably 
gives nothing more: 

KUrl url;
QString path;
QFile file;

i18n("%1 %2 %3") << url << path << file << endl;


-- 
regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

Sponsored by OpenOffice Polska to work on
* Kexi & KOffice: http://www.kexi-project.org | http://koffice.org/kexi
* KDE3 & KDE4 Libraries For Developing MS Windows Applications:
                   http://www.kdelibs.com/wiki
See also:
* Kexi For MS Windows: http://kexi.pl/wiki/index.php/Kexi_for_MS_Windows
* Kexi Support:        http://www.kexi-project.org/support.html