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

List:       kde-i18n-doc
Subject:    Re: Keeping HTML code out of i18n()'d labels
From:       Burkhard =?iso-8859-1?q?L=FCck?= <lueck () hube-lueck ! de>
Date:       2010-11-30 12:34:42
Message-ID: 201011301334.43681.lueck () hube-lueck ! de
[Download RAW message or body]

Am Dienstag, 30. November 2010, um 08:18:31 schrieb Akarsh Simha:
> > > One of our GCI tasks is to create useful information links for every
> > > technical term in KStars, and our student has successfully implemented
> > > it already.
> > > 
> > > Now, this involves changing the text of several labels in several .ui
> > > files to include HTML tags: "<a href="foo">foo</a>" instead of "foo".
> > > 
> > > My question is, is $EXTRACTRC going to take care of getting rid of the
> > > HTML tags, or will it extract the string inclusive of the HTML tags?
> > > If it is the former, do we need to add some context?
> > 
> > Why do you want to get rid of the links?
> > In the german team we'd like to have them translatable, e.g. replace a
> > link to the english wikipedia page with the appropriate link to the
> > german wikipedia page, if there is any. There is no need for context in
> > such a case.
> 
> Hi Burkhard,
> 
> In this case, we were dealing with internal links to the KStars
> handbook -- so they wouldn't require to be translated, right? 

Yes, internal links to anchors in *must* be untranslated to work, this should 
be added as context.

> But
> then, we might want to link to external sources in a similar manner at
> a later stage anyway.
> 
> Thanks for the clarification!
> 
> > > Also, I think that this tiny feature would be awesome to have in 4.6,
> > > but of course there's the feature freeze and the string freeze on
> > > trunk now. I wanted to know if we can make an exception _if_ there are
> > > no strings changed. (It is not worth, for sure, if this is going to
> > > change strings)
> > 
> > How many strings are effected, 10 or 100?
> > Can you please provide a link to the archiv with these changes?
> 
> I don't think we have more than 10 strings affected. The latest
> version of the patch has not yet been commited anywhere, but an older
> version is on reviewboard here:
> http://reviewboard.kde.org/r/5983/diff/#index_header
> 
> This old diff pretty-much captures all the string changes, except that
> one more might have been introduced in the final version of this
> (which I haven't seen)
> 
> Do you think we should push this into trunk? It's not really
> necessary, but I think it might be cool to have. If it's a pain for
> translation teams, let us not bother about it at all.
> 
German team wold prefer to get that into trunk asap.

-- 
Burkhard Lück

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