digling / burmish

LingPy plugin for handling a specific dataset
GNU General Public License v2.0
1 stars 1 forks source link

Old Burmese Sound Check #30

Closed LinguList closed 8 years ago

LinguList commented 8 years ago

https://github.com/digling/burmish/blob/master/sounds/sounds.md#old-burmese

nh36 commented 8 years ago

In Old Burmese y is [j] c564 not [y] v166.

nh36 commented 8 years ago

In Old Burmese ṅ is [ŋ] c795

nh36 commented 8 years ago

In Old Burmese 17 o v042 5 should not occur. It should either be o1 or o2. I will have to look at the cases in question.

nh36 commented 8 years ago

For our current purposes o₂ in Old Burmese can be interpreted as [u] v027. Although this is not an altogether un-problematic identification.

nh36 commented 8 years ago

For our current purposes o₁ in Old Burmese can be interpreted as [o] v042, although this is not an altogether unproblematic identification.

nh36 commented 8 years ago

Old Burmese nh nʰ c096, mh mʰ c243, and lh lʰ c541 are incorrect identifications. These should be identified as voiceless rather than aspirated. m̥ c235, l̥ c538

nh36 commented 8 years ago

Same goes for rh rʰ. this identification is not correct it should be voiceless.

nh36 commented 8 years ago

In Old Burmese c refers [ts] c015 and not to [c] c600.

nh36 commented 8 years ago

We can treat ḥ as ɦ, I guess. It is a bit tricky, because in Burmese (lets say Rangoon Burmese) it is a character that is used to mark a tone and apparently the Burmese tones have regular correspondences with Lolo-Burmese tones, so they are tones all the way back, but Nishi suggests that in Old Burmese the tones may have been phonation types, and he reconstructs ɦ in (shall we call it) pre-Burmese.

nh36 commented 8 years ago

The 'long vowels' are also ways of marking tone, but for the reasons mentioned immediately previously, we can interpret as follows ā > a: ī > i: ū > u:

LinguList commented 8 years ago

I guess I should think about introducing the possibility to add A/B-distinctions to include historical information in the lists. I mean, like the Old Burmese h with dot, this is a distinction we do not want to loose, but we may want to NOT give it any direct value. Without wanting to encourage people to be indistinctive about all their data, I could add either the possibility to tolerate a symbol by CLPA that is data-set-specific, or I could add dymmy-symbols meaning "unspecified", where one has but to choose to which type it belongs. In this case, we could just treat it as a tone for the moment, and say that h with dot is tone capital superscript H, or some other convention for EXPLICIT user-definied things with unspecified values.

In the end, this symbol would be a composite-symbol: one marker, that says, which basic type (consonant, vowel, tone) it is, and after-wards, a user-defined symbol that would be free for annotation. I'll reflect about this and see how feasible it is to get it integrated into the CLPA proof-check-system.