[tei-council] Things needing translation

[Syd Bauman]

Overall, I like the idea. I particularly like the idea of opening
this up to languages we don't already have (we just hired a student
whose native tongue is Persian :-), and including the current
translation for review.
Several issues jump to mind, though.

MH> ... script a system which would look at the translation dates,
MH> check out svn versions of the files from those dates, and diff
MH> the English definitions against the current ones to find out
MH> whether updates are needed.

SR> ... not impossibly hard

1) Martin and Sebastian are working extra hard to get the information
   we need, here, because (IMHO) we did not set up use of the
   versionDate= attribute well when initial translations were done.
   (If *Sebastian* says "not impossibly hard", it's too hard. :-)
   Currently, versionDate= is put on the non-English <desc>, <gloss>,
   <exemplum>, <valDesc>, or <remarks> only. I.e., it is not put on
   the canonical <desc>, just the translation <desc>s. (There are 6
   exceptions.) This, it seems to me, is a mistake. If we required
   versionDate= to be on every att.translatable element that was, in
   fact, translated (including the canonical), then the comparisons
   would be *much* easier, no? Or am I missing something, here?


SR> column 1: element/class name
SR> column 2: attribute name (where appropriate)
SR> column 3: <desc>
SR> column 4: translation (if any)
SR> column 5: <gloss>
SR> column 6: translation (if any)
SR> column 7: <remarks>
SR> column 8: translation (if any)
SR> column 9: reap statement (optional)

2a) What's a "reap statement"? 

2b) I'm a bit nervous about using a spreadsheet for data that could,
    often should, and occasionally will, contain markup.

2c) Most importantly, no matter how people are entering this, it
    seems to me we need to give them an opportunity for entering
    notes or discussion. We want to encourage (I think) the
    back-and-forth of "why did you translate X as Y? wouldn't Z be a
    better term?", etc.

2d) Don't we need to include the date for versionDate=, too? (Or are
    you planning to extract that from the GoogleDoc history, in which
    case you are a braver man than I -- although we all knew that
    already. :-)


MH> ... make the spreadsheets completely public-editable, or ask
MH> people to request access so there's some vetting[?]

SR> i'd go for public access. simpler than trying to vet people.

3) I (pretty strongly) feel that

   a) We should not outright vet people -- we are no judge as to who
      is a good Persian translator and who isn't.

   b) Nonetheless, we *absolutely* should require a sign-on process,
      preferably one that lets us obtain a real name and e-mail
      address. That is, the general public should be able to
      contribute, but not anonymously. 
      One reason for this, BTW, is that we do not have the resources
      to check that some 14 year-old hasn't put something in there
      that is really inappropriate, let alone makes your grandmother
      blush. But at least if people have to own up to what they say
      they are unlikely to abuse, and we can look for other problems
      once one is found, etc.