Revert of hrc cleanup

Michael Meeks michael.meeks at
Fri Jul 20 06:34:57 PDT 2012

Hi Thomas,

On Wed, 2012-07-18 at 21:33 +0200, Thomas Arnhold wrote:
> as Markus stated in dc05a825e71316e6f602e5c8dfcd3d10ecb6252f those 
> string cleanups aren't save. I've had the illusion, that by compiling 
> and "quick checking" all of it got tested (mostly by compiling). 

	Ah ... ;-) right; so it's necessary to check the code to ensure that
arithmetic is not used to pick items in a range; it's necessary to read
the hrc file to check that out really. Of course, if no pattern is
visible in the hrc file, and/or there is no comment there - IMHO the bug
is that that is not clear, and we should revert just that bit, and
annotate / clarify the .hrc or .src file itself.

> Because there were complains, if I removed too much. I didn't touch things like 
> STR_FOO_BEGIN 100 and STR_FOO_END 200 if there were definitions inside 
> it and STR_FOO_BEGIN or STR_FOO_END were seen in the source.

	Oh - so, of course, people also use that pattern in ways that are not
string lists. IMHO there is no really good way to detect this short of
seeing a few missing strings, and having an idea of where to poke to
restore them.

> So I revert all of those string changes now. Because I can't ensure that 
> there are more of those errors. Moreover I did remove a massive removal 
> of resource ids.

	Well - if a .hrc is removed; and is not referenced in any .src file,
nor any .cxx file (on each platform) then that is just great.

> Is there any way to get a real checkup what string and definitions are 
> in use at all?! If not it would be safer to revert all of this cleanup. 
> Even if that's very sad...

	Basically no - it's very sad and broken :-) hence the need for a robust
cleanup tool; and (in future) some better l10n infrastructure.

> I don't wanted to mess all of this up.

	Hey - you did good ! it's a great area to work on cleanup for; the fact
that there are a few problems is expected with any development. And the
navigator code is a particularly unpleasant example of cut/paste coding
from the stone-age :-) so it's expected to break a lot.

	It'd be great if you could go back through the patch & do some more
checking in the code for arithmetic relating to SIDs - if possible ?

	Thanks !


michael.meeks at  <><, Pseudo Engineer, itinerant idiot

More information about the LibreOffice mailing list