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

List:       kdevelop-devel
Subject:    Re: question about translations in grepview
From:       David Nolden <zwabel () googlemail ! com>
Date:       2011-02-04 14:11:52
Message-ID: AANLkTi=D8WvYiAWjAk96PEmsCXhj_CqqjWE+rFUF0hDP () mail ! gmail ! com
[Download RAW message or body]

2011/2/4 Gerhard Stengel <gstengel@gmx.net>:
> Hi,
> 
> I just tried to update de-translations for kdevgrepview.po vor kdevelop 4.2.0.
> 
> There is a huge html help text which comes from grepwidget.ui, line 69, the \
> translated version of which doesn't show up. I cross checked sv and fr and it \
> doesn't work there, too. Is there a problem that the i18n function can't cope with \
> such big html texts? Or do I have to set something special in the html header?
No clue about this one, maybe someone else can answer it. I think
stuff in ".ui" files should be translated automatically, without
requiring any i18n.

> Secondly, there are some untranslatable texts in the code browser. If I click on a \
> "container", I get an outline of the container (OK), but the first line starts with \
> "Back to" which can't be translated anywhere. In this context I think it's a bit \
> inconsistent that the keyword "enum" is translatable, but "struct", "union" and \
> "class" aren't (whether it's reasonable to translate this is a matter of taste, \
> though...).

I've added "Back to" into i18n. There is no place though where "enum"
is translatable, I've only found "Enum:" and "enumerator", which both
are not C++ keywords, so it's maybe ok to translate them. C++ keywords
though should _never_ be translated.

> Last question: I think the pattern separator doesn't work as it shoud in the new \
> find/replace dialogue. If I want to search something i.e. in a *.h file, it work \
> fine. Same for an *.cpp file. But if I separate those two by a space (as the help \
> text suggests), it doesn't work an more. By default, the patterns are separated by \
> commas which makes me think that the help text may be wrong, but it doesn't work \
> either way. Sometimes I don't succeed to find anything, even though the searched \
> string is obviously present in the code.

I have fixed this issue in the plugin. It only considered "," as separator.

Greetings, David

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


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