KDE4 proposal: Paths in i18n strings
Jarosław Staniek
js at iidea.pl
Mon Jul 3 23:39:58 BST 2006
> 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
More information about the kde-core-devel
mailing list