|
From: walter h. <wh...@bf...> - 2007-04-27 07:35:49
|
Craig Small wrote:
> On Thu, Apr 26, 2007 at 12:50:04PM +0200, Bernhard R. Link wrote:
>> 1) translations
>> I don't know if the last patch for moving seperatly translated and
>> outputted string into single chunks still applies cleanly. If not
>> I can prepare a new one. That will need some work to bring the
>> .po files up to date. Did I remember correctly you volunteered for that?
> First I need to know if it is ok to submit it to the TP project, which
> is where a lot of programs get their translations. If so, yes I'll
> handle the translation handling part.
>
> What generally happens is you get reasonably happy with the code,
> especially any strings, you freeze that bit. Then we send the lprng.pot
> file off to the translators.
>
> Before that can happen, it needs to get into the project. I would
> strongly recommend it goes to the TP. The next thing is do we require a
> disclaimer (for me the answer is yes). What it does it means the
> translators do claim copyright on the translations, so it doesn't mess
> up the copyright of the program. All GNU programs use the same
> disclaimer.
>
the old code runs with artistic licence. Personally i do not care,
is that compatible with your request ?
> If everyone is happy with that, I'll start talking to them about this
> project and warming them up.
>
> Bernhard, can you put that patch in to "chunk up" the text blocks? It
> will make things easier for the maintainers. Once you have done that
> I'll fool around with the gettext stuff to get that working.
>
> Then let me know once you have finished with the strings and I'll send
> off a .pot file to the translators, give them say a week then we can
> release.
>> 2) walter likes to make the assymetric-parenthesized macros go away.
>> As that would break most larger patches, there are both good
>> arguments for making it before the first new release and for making
>> it after the release. (Depending where one expects patches to come
>> from more).
> I'd like those macros go away, but I don't think it is required for THIS
> release. I have often found it useful to follow the "release early
> release often" way of doing things. As long as the code is ok.
these unbalanced () are a problem for any indent program. It is a very very wired
idea. The code has some very large blocks and is really helpful if you can figure out
where the "}" belongs to without emacs getting confused by a not closed "(".
I hope that i reason enough.
We should have does it with the first release but brl is reight that patches will
become more useless.
>
> Has anyone tested the new code on something that isn't a i386 device?
> I've got access to a lot of wierd and wonderful arches, if required.
oh yes please, since our department did the 'clean up' i have only access to
i386 (an some embedded chipsets but that hardly does not count).
simply run it and give as an idea what breaks (if something break at all).
re,
wh
>
> - Craig
>
|