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

List:       kde-i18n-doc
Subject:    Re: RFC: To kde.pot or not to kde.pot
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2006-04-13 14:11:32
Message-ID: 200604131611.34534.nicolasg () snafu ! de
[Download RAW message or body]

On Thursday 13 April 2006 15:35, Nicolas Goutte wrote:
> On Thursday 13 April 2006 11:48, Diego Iastrubni wrote:
> > Hi,
> >
> > I say no. I even think that more strings must be on that file. One thing
> > I am thinking of, is country names and month names. I have translated
> > them in 2 different places, and I can easily see this happening even more
> > times.
>
> I think that it is not the right place for that.
>
> Month names are in kdelibs.po, as for country names, it is to be seen where
> they will be put in KDE4, but that too will be a public PO file.

To be clearer: this will need code to call those strings (even if probably for 
later than KDE4). But that way it would be clearer than using kde.pot and if 
an application really need to duplicate a string it could be done easily 
without kde.pot.

Also do not forget that we are heading toward stripted translations. Using 
kde.pot in that case would mean that all script for such a translation 
(e.g. "Open") would need to be in kdelibs.po for the whole of KDE4.

Have a nice day!

>
> Have a nice day!
>
> > just my 0.02 cents
> >
> > ביום חמישי, 13 באפריל 2006, 12:35, נכתב על ידי Stephan Kulow:
> > > Hi!
> > >
> > > We currently exclude the content of kde.pot from all generated pot
> > > files. The idea was to avoid duplicated translations, but it caused
> > > problems in the past where it wasn't possible to overwrite certain
> > > strings in some apps.
> > >
> > > So I'd like to know if you see the benefits of it higher than the
> > > problems associated with it? Because it's easy to remove that kde.pot,
> > > but it would add quite some strings to translate (to KDE4 - don't worry
> > >
> > > :)
> > >
> > > Greetings, Stephan

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