Re: A few things to note

[Isam Bayazidi <bayazidi at accessme dot com>]

On Thursday 01 November 2001 20:33, you wrote:
> On Thu, Nov 01, 2001 at 10:26:36AM -0800, Nadim Shaikli wrote:
> > Wouldn't a Makefile type approach suffice ?  In other words, note the
> > files that were committed to KDE and do incremental commits there after.
>
> Well, that is not really the issue here. The mechanism by which commits
> to KDE happen are not a problem (and yes it's on my list to automate by
> shell script - actually I *do* use a shell script, but not sophisticated
> enough to tell diffs.. just chekcks for certain files, copies ones over,
> etc.).
>
> The problem is, how do I prevent translation work to continue on files
> which may have/will be modified when it goes over the KDE side. In other
> words, how do we minimize lost work from Arabeyes translators while
> keeping up with KDE? Locking the kde-i18n module will give us time to make
> sure no one changes anything until KDE says, okay your files are good to
> go, or.. oh, this file here has two extra strings, here they are. Then I
> would grab those files and put em back on Arabeyes CVS. In the meantime,
> someone may have continued to translate some more strings on the same
> file.. see where I'm going?
Well I am not for freezing or locking the kde-i18n/ in our repository, for 2 
reasons.. first, as most of the changes is the addition of new strings and/or 
moving some strings from one file to another, work done by the team will not 
get wasted, I worked in the kdelibs.po file after it changed, fixing the 
fuzzy strings, and adding strings didn't take much time, and the strings 
deleted (omitted) from the file ( found commented at the end of the file) 
where not that much compared to the file size ( around 1900 message total 
size) .. so I will not worry about it..
Second reason, I thinking freezing the kde-i18n is not to be done while 
translation is underway, it could be understood ( and it is always done in 
projects) when the project is done and the work done is mostly bug fixes.. 
but in our case, most of the work is translation, and this is what we should 
not prevent ( lock)..

Another issue that came to my mind, How does the KDE people determine if our 
Translation is OK and acceptable ? can they provide us with their 
tools/methods so that we only commit to the KDE project what is OK .. just a 
thought ..



-- 
		Yours
			Isam Bayazidi
			Amman- Jordan