KDevelop 3.4 translations.

Hi,

The KDevelop team is planing to release stable KDevelop
3.4.x versions 
together with KDE 3.5.x

We already released 3.4.0 with KDE 3.5.6 but it did not
contained any 
translations :(

apaku and I looked at this script:
/trunk/l10n/scripts/get_paths

And it looks like all it takes to extract and pass the
KDevelop strings from 
the /branches/kdevelop/3.4 to the translators is to add a
case to the 
get_paths switch statement.

Can you confirm/deny it ?

Will it work, can I do it ?


-- 
Amilcar Lucas
Webmaster
The KDevelop project

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Am Montag, 19. Februar 2007 16:19 schrieb Amilcar do Carmo
Lucas:
> Hi,
>
> The KDevelop team is planing to release stable KDevelop
3.4.x versions
> together with KDE 3.5.x
>
> We already released 3.4.0 with KDE 3.5.6 but it did not
contained any
> translations :(
>
> apaku and I looked at this script:
> /trunk/l10n/scripts/get_paths
>
> And it looks like all it takes to extract and pass the
KDevelop strings
> from the /branches/kdevelop/3.4 to the translators is
to add a case to the
> get_paths switch statement.
>
> Can you confirm/deny it ?
>
> Will it work, can I do it ?

It would extract 3.4 translations into trunk, but I just
told the translators 
that trunk is dead for kdevelop - and at least 60%
acknowledged 
So I'm not sure it would be wise - it's a mess anyway
though.

Greetings, Stephan

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 19 February 2007 17:17:43 you wrote:
> It would extract 3.4 translations into trunk, but I
just told the
> translators that trunk is dead for kdevelop - and at
least 60% acknowledged
> 
So I'm not sure it would be wise - it's a mess anyway
though.

We do not want if for trunk.
We want it for stable. Is that possible.

We think that merging branches/kdevelop/3.4 branch into
branches/KDE/3.5 just 
to have translations is a big overkill.

KDevelop 3.4 source code belongs in it's own stable branch
like it is now 
(branches/kdevelop/3.4).
KDevelop 3.4 translations should be moved to stable without
moving the source 
around.

Is that possible ?

-- 
Amilcar Lucas
Webmaster
The KDevelop project

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Am Montag, 19. Februar 2007 17:41 schrieb Amilcar do Carmo
Lucas:
> On Monday 19 February 2007 17:17:43 you wrote:
> > It would extract 3.4 translations into trunk, but
I just told the
> > translators that trunk is dead for kdevelop - and
at least 60%
> > acknowledged
> >
> >  So I'm not
sure it would be wise - it's a mess anyway though.
>
> We do not want if for trunk.
> We want it for stable. Is that possible.
Then your trunk/l10n path is wrong for what you want to
achieve.
>
> We think that merging branches/kdevelop/3.4 branch into
branches/KDE/3.5
> just to have translations is a big overkill.
>
> KDevelop 3.4 source code belongs in it's own stable
branch like it is now
> (branches/kdevelop/3.4).
> KDevelop 3.4 translations should be moved to stable
without moving the
> source around.
>
> Is that possible ?

Then you drop the kdevelop 3.3 releases? Or will _those_
come without 
translations then?

Greetings, Stephan

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 19.02.07 17:48:18, Stephan Kulow wrote:
> Am Montag, 19. Februar 2007 17:41 schrieb Amilcar do
Carmo Lucas:
> > We think that merging branches/kdevelop/3.4 branch
into branches/KDE/3.5
> > just to have translations is a big overkill.
> >
> > KDevelop 3.4 source code belongs in it's own
stable branch like it is now
> > (branches/kdevelop/3.4).
> > KDevelop 3.4 translations should be moved to
stable without moving the
> > source around.
> >
> > Is that possible ?
> 
> Then you drop the kdevelop 3.3 releases?

We already did so quite some time ago, i.e. there haven't
been any
changes in 3.3 for nearly a year.

> Or will _those_ come without 
> translations then?

AFAIK the 3.3 version is translated as is the rest of KDE
3.5. 

The problem is that these translations are installed by
distro's along
with the kde-i18n packages and with a kdevelop3.4 that makes
a real
messy GUI, having native and english texts mixed all over
the place.

Is there any way to have this changed with the next .x
release of KDE
(if it happens) without moving KDevelop into
branches/KDE/3.5/kdevelop?
We heard that for koffice 1.x the messages are extracted via
scripty and
the translators see them, so we checked how that might work
and found
the get_paths() function which seemed to do so...

Andreas

-- 
Your own qualities will help prevent your advancement in the
world.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 19 February 2007 17:48:18 you wrote:
> Am Montag, 19. Februar 2007 17:41 schrieb Amilcar do
Carmo Lucas:
> > We do not want it for trunk.
> > We want it for stable. Is that possible?
>
> Then your trunk/l10n path is wrong for what you want to
achieve.
branches/KDE/3.5/l10n does not exist. Where should I look
for them ?

> Then you drop the kdevelop 3.3 releases?
Yes, KDevelop 3.3 is no longer under development.

KDevelop 3.4 is the stable branch now.
trunk/kdevelop is the development branch.

Thanks,

-- 
Amilcar Lucas
Webmaster
The KDevelop project

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Merging the kdevelop/3.4 branch into KDE/3.5 branch will
bring us some 
problems:

- Confuse the users that do use svn checkouts
- Make me change tons 15+ website files (I still have no
clue how to change 
the top table of the branches_compiling.html page in a nice
way)
- Confuse our website translators

To avoid that all we need to do is to change two files in
KDE source tree,
branches/stable/l10n/scripts/get_paths
  has the translation path of the stable releases,

branches/KDE/3.5/kde-common/release/versions
  has the source path of the stable releases.

This has the advantage of preserving history and requiring
the less amount of 
changes/confusion.

And NO, that distro packagers will not be confused by this,
they just grab the 
tar.bz2 files that we provide them, they do not use SVN.
If they do that (use SVN), then why the hell do you provide
tar.bz2 files ?

-- 
Amilcar Lucas
Webmaster
The KDevelop project

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Am Mittwoch, 21. Februar 2007 10:38 schrieb Amilcar do Carmo
Lucas:
> Merging the kdevelop/3.4 branch into KDE/3.5 branch
will bring us some
> problems:
>
> - Confuse the users that do use svn checkouts
How does it confuse them? Because they out of the sudden get
the maintained 
version and no longer the "who cares" version?
Yeah, I can see their problem 
with that.

> - Make me change tons 15+ website files (I still have
no clue how to change
> the top table of the branches_compiling.html page in a
nice way)
> - Confuse our website translators
Oh boy, how many of them do you have? 20? How many users are
confused because 
you need kde-i18n of KDE 3.5.7 for kdevelop 3.4?
>
> To avoid that all we need to do is to change two files
in KDE source tree,
> branches/stable/l10n/scripts/get_paths
>   has the translation path of the stable releases,
>
> branches/KDE/3.5/kde-common/release/versions
>   has the source path of the stable releases.
>
> This has the advantage of preserving history and
requiring the less amount
> of changes/confusion.
>
> And NO, that distro packagers will not be confused by
this, they just grab
> the tar.bz2 files that we provide them, they do not use
SVN.
> If they do that (use SVN), then why the hell do you
provide tar.bz2 files ?
They do use the tars, but they often grab bug fixes from the
3.5 branch.
At least remove the kdevelop in that branch and replace it
with a directory 
that only brings a README

Greetings, Stephan


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Wednesday 21 February 2007 10:46:17 you wrote:
> > - Confuse the users that do use svn checkouts
>
> How does it confuse them?
> Because they out of the sudden get the maintained 
> version and no longer the "who cares"
version? Yeah, I can see their
> problem with that.
- The ones who check out the kdevelop/3.4 branch will
suddenly get the "who 
cares".
- The ones locked at having to use a old KDE 3.2 or 3.3 that
do _need_ 
kdevelop 3.3 will suddenly get a "better"
KDevelop, but that does not compile 
anymore.

> > Confuse our website translators
> Oh boy, how many of them do you have? 20?
yeap, around 20.

> How many users are confused 
> because you need kde-i18n of KDE 3.5.7 for kdevelop
3.4?
KDevelop 3.4.1 will be released with KDE 3.5.7. Why will the
users be 
confused ?

-- 
Amilcar Lucas
Webmaster
The KDevelop project

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Am Mittwoch, 21. Februar 2007 10:56 schrieb Amilcar do Carmo
Lucas:
>
> KDevelop 3.4.1 will be released with KDE 3.5.7. Why
will the users be
> confused ?
OK, I begin to understand your situation. Let's talk about
the KDE translators 
who will be confused 

Have you their OK? I'm not sure they are aware what you're
planning.

Greetings, Stephan

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel