Personally I don't think having historic information beyond stats (e.g.
which strings were missing, identical, etc.) is important, that
information is relevant only for a short span of time before the current
build.
So my vote would go to throw away that data.
Francesco
Hi,
I'm working on a series of changes to compare-locales towards a 2.0
version.
Meaning, I'll break backwards compatibility.
One of the things I'd like to break still is backwards-compat of the
json output of compare-locales.
Do folks here (and there, as I'm posting to two lists) care?
Also, the compat change calls for a hard question on historic detail
data on l10n.m.o. I'd not change the stats, but the detailed links
that show which string is missing and which is obsolete a month ago
would be deleted.
I'd not change the fact that you can get to current details and error
reports. Just that I would delete the data going back in time, rather
than figuring out how to regenerate it, or maintain two code paths.
Rationale: I've had numerous requests over the course of time to show
data per file in the order in which it is in the file. Right now, I
store data as a dictionary like:
{
"missingEntities" : [ "aMissingThing", "bWouldBeGood"],
"obsoleteEntities" : ["whyWouldYouHaveThis", "yesThisCanGo"]
}
Obviously I can't add file order between missing and obsolete in that
schema. So to add file order, I need to change the schema, and then
the question arises of what to do with the old data.
The easiest way to handle this is to throw it away. And I'm pretty
sure that's OK.
But I wanna make sure it is.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
