From kde-i18n-doc Fri Feb 13 13:46:02 2004 From: blackie () kde ! org (Jesper K ! Pedersen) Date: Fri, 13 Feb 2004 13:46:02 +0000 To: kde-i18n-doc Subject: Re: Reminder KimDaBa release tomorrow. Message-Id: X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=107668000215715 Jeroen Wijnhout 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.