Open arlogriffiths opened 4 years ago
<supplied reason="subaudible">
, analogous to supplied avagrahas. But my inclination keeps changing. Gabby on Markup seems set against introducing a new value for supplied.<citedRange>
Wouldn't "item" be suitable? Now suggested for "a number in an anthology", but if we discard the idea of displaying that as №, it could be applied to such entries. But on second thoughts, perhaps indeed better to keep "entry" distinct. Display as "s. v."? Give me a final word and I'll add it to the EG.<quote>
may be fine, but by the TEI Guidelines, that is normally for "Quotations from other works". Perhaps <q>
is better suited for this purpose, but that would introduce yet another markup element that we do not use otherwise (unless we adopt it for italicisation, which I hope we don't.) At any rate, we should indeed agree on some form of markup, which has the advantage of automatically producing the correct quotation marks.<choice><orig>susuku</orig><reg>susuk ku</reg></choice>
. (@danbalogh : agreed? this means enclosing two words in a single <choice>
.)@unit="entry"
to EG and state explicitly that it is intended to be displayed with s.v.<quote>
is to be used also to achieve quotation marks around translations of words or phrases, but that if the encoder insists he can override our transformation by typing precisely the unicode signs for the desired quotation marks („...” “...” ‘...’ «...»). Then please add a comment to the new bit of EG contents asking @ajaniak to express her opinion.The EG stubs are done. See added text in red under §6.1/Good practice in normalisation, §6.2/Editorial deletion, and §6.2/Editorial addition.
Note that there is also the option of just flagging
I think your suggestion is preferable even if we adopt a method for adding individual characters as normalisation. There will need to be some indication of this in the EG. In your suggestion to Aditia, is <reg>susuk ku</reg>
deliberate or is it a typo for <reg>susuk· ku</reg>
? I cannot give you a qualified opinion on which would be better, but it seems to me that the latter would be more apt.
Given what Gabby said on Markup about how most people view normalisation, we should still consider how extensively we want to normalise. Flagging may be preferable in most cases, and it is in fact what the EG says at the moment under Good practice in normalisation, which does not explicitly recommend normalisation for any phenomenon, and instead groups non-standard features into three classes, with the following recommended strategies:
Arlo, please add some thoughts in comments to the EG, and we should probably have a Skype discussion one of these days.
3 and 4 are done.
Arlo, is there anything in this issue that still needs action from me?
@danbalogh I have just pushed a version of the file with some questions addressed to you. Please answer here.