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

List:       kde-i18n-doc
Subject:    Re: Reminder KimDaBa release tomorrow.
From:       blackie () kde ! org (Jesper K !  Pedersen)
Date:       2004-02-13 13:46:02
Message-ID: lwad3n6qjp.fsf () catatonia ! blackie ! dk
[Download RAW message or body]

Jeroen Wijnhout <Jeroen.Wijnhout@kdemail.net> writes:

| On Friday 13 February 2004 14:16, Jesper K. Pedersen wrote:
| > I'm not sure I fully understand what you suggest, so let be elaborate on
| > what I try to obtain:
| >
| > 1) I'd like to branch out, so I can continue development on HEAD, but still
| > also be able to release a branched version
| 
| That what I did a few weeks ago, it is possible in the current setup. Updating 
| translations within a branch is a different story.
| 
| > 2) The branched version should allow for bug fixes both in i18n's but also
| > allow for adding new strings to be translated - limited as much as possible
| > of course
| 
| That would be hard to do. Translators would _have_ to know about the branch. 
| Also scripty needs to know about it (so it can update the .po files in the 
| branches as well). For that the script run by scripty needs to be modified, 
| unless somebody is volunteering to do this, it probably has little change it 
| is going to be implemented.
I imagine I would personally do the job of scripty, I did so for this
message freeze too, as scripty was not running at that time.

| > 3) New language should be able to be added for the branched releases, thus
| > if say the Icelandic translation team wanted to create a translation for
| > KimDaBa for a branch version, then that should be possible.
| >
| > I don't know if this is overkill, but next version of KimDaBa should
| > preferable include a plug in mechanism, and maybe also some KPart stuff,
| > which I expect could take some month before being ready for release, and
| > adding to that some time for other stuff plus release freeze phase etc the
| > total life time of KimDaBa 1.1 would be 4-6 month.
| >
| > I'm not sure I understand if there is any implication to other people
| > of tagging all of kde-i18n (and if there is what). If there is, please let
| > me know.
| 
| It would mean an overkill of tag/branch names in CVS. But more importantly, 
| you do not _need_ to do that. The cvsExtract.sh script will look for all 
| translations in CVS (in the respective branch), so they will be added 
| automatically.
I'm not sure you understand my problem (or I do not understand your
solution ;-)
so let me show it to you:

Day 1: KimDaBa version 1.1 is released
Day 2: Jesper continues working on HEAD, adds some strings, and more
important delete or modifies other strings.
Day 3: scripty executes, and updates the templates
Day 4: A translator wants to translate version 1.1 to be included in 1.1.1,
but he can't simply do that because the templates are now for HEAD.

Of course, that would not require a branch of all CVS.

| Adding new strings within a branch is currently just not possible.
Which is what I'm trying to overcome, perhaps its not worth the effort, but
who know.

| > I do of course not want to be intrusive to anyone, but do rather try and
| > make it possible for translators to pick up translation for 1.1.x after 1.1
| 
| It is possible in the scheme I suggested. New strings won't get added in that 
| branch, however, unless somebody convinces Coolo to do modify his kde-i18n 
| script.
| 
| > release plus make it possible for the users to get maintenance
| > version more often.
| 
| You can still release within a branch, but tjhe maintenance release shouldn't 
| contain new strings, that's all. AFAIK the KDE_3_2_BRANCH is still frozen as 
| well.
Right, that is a very convincing argument, but that makes me wonder what
that branch is needed for then, then a tag would be enough....

Would this work:
1) I agree not to add any new strings for 1.1.x releases compared to the
1.1 release

2) I tag only kimdaba.po files and docs/../kimdaba/*

3) If a new team wants to add a translation for KimDaBa 1.1.x, then they
would need to check out the templates in KimDaBa for 1.1, and would need to
explicit themself set the tag kimdaba_1_1_release to get their files
includes with the 1.1.x releases.

Is the above worth the trouble at all, or should I just conclude that no
new translations will show up in 1.1.x releases? What I'm really aiming at
here is to ensure that translators see their translation with their users
as soon as possible, that is, do not have to wait 4-6 month before it gets
there, but I might be trying to solve a non existent problem.

Finally, should I remove the tag + branch for everything irrelevant again
or would that just make things worse?

Cheers
Jesper.
[prev in list] [next in list] [prev in thread] [next in thread]