Organized Error Localization "Bug" Hunt/Sprint

[Lech Deregowski]

I've presented Mitcho with a brief of my plan and now I'm going to
need a little help from those of you whom can make changes to Hg
(Blair, Brandon, Jono, Mitcho, Satyr and anyone else I'm missing who
will want to help) to lend me their hands and eyeballs. Over the next
few patches I will begin to introduce the following comment tag before
some strings:

//errorToLocalize

The reason for me adding this is because we haven't fully decided
whether or not to translate error strings, because I'm not sure which
may or may not be helpful to the user. We'll have to decide that
eventually, and preferably well before hitting the 0.6.0 milestone in
order to get the necessary files out to Babelzilla and back in time
for release. So I'm organizing a bug hunt for this purpose to make the
necessary decisions as a group in a fast (and maybe fun?) bug hunt/
sprint session to hopefully get it done quickly.

What I'll be doing in the meantime is collecting these strings into a
temporary file, assigning keys to them and attempt to keep track of
what file I tagged them in. All of that work should be done before the
day of said hunt so I'll have keys ready and waiting. What I will need
of you is a couple of hours at most to help me move all those keys
into those files while I move the temporary keys into place within
their respective DTD or Properties file. The comment tag I'm inserting
should hopefully make it easier in finding position, and since you
guys have access to review and commit changes faster than I do as we
go along it should hopefully go very smoothly.

I want to allow translations for many of these error message strings,
but in doing so I know we'll lose context when a user is reporting
seeing the error on GSFN or elsewhere. The only remedy for that which
I can think of off the top of my head is organizing errors by type and
prefixing each one with some number so we can quickly reference it
(ala http response codes) to get an idea of what problem the user is
actually reporting. It's not a perfect solution but until someone has
a better idea I am open to suggestions on that one.

Alternatively, we can always leave these errors in English which may
not be very helpful for everyone. So we may want to decide on a
deadline of when we want to carry this plan out if we choose to go
through with it, and figure out how to organize errors. I'm open to
suggestions, please discuss.

-L

["mitcho (Michael 芳貴 Erlewine)"]

Lech,

Thanks for taking a lead on this. I'm for localizing the errors and
attaching error numbers to them. As ugly as error numbers are,
combined with localized errors it will probably not be too un-useful,
and the fact that there are ID numbers will mean that we will be able
to act on error reports (or even automated bug reports!) which
reference the localized error text.

jm2c

m

--
mitcho (Michael 芳貴 Erlewine)
mit...@mitcho.com
http://mitcho.com/
linguist, coder, teacher

[Lech]

Not a problem, I'm about 30% through scrubbing the core for strings
and tagging lines which may need a translation while making notes for
files which I'm unsure of.

-L

[Lech Deregowski]

OK, I forgot to update this thread but the collection has been
complete for a little over a week now but we still have nothing in
terms of how to organize said errors. Any ideas? this is the last of
the localizations.

-L