Some simpler alternatives that don't involve moving out of ASCII: (1) ee = [e] e = [ɛ] ii = [i] i = [ɨ] * (2) ei = [e] e = [ɛ] ii = [i] i = [ɨ] * (3) iy = [i] i = [ɨ] ey = [e] e = [ɛ] * (4) i = [i] ui = [ɨ] e = [e] ae = [ɛ] If the romanization is intended to be used, I think ease of use and recognizability should trump other concerns. Unfortunately one then has to take into account the keyboard layouts and languages of the bulk of one's audience. Since the majority will be using keyboards that require extra effort to use accented characters, accented characters should be avoided if possible. In this case, I think it's entirely possible. This, of course, is only if the romanization is intended to be used. If it's just for the author, then only the author's concerns need be taken into account. If others are ever going to use it, though, I think the romanization should be treated like an auxlang: as simple as possible and as recognizable as possible. The only time when this wouldn't be the case is when the romanization system is also the orthography (e.g. as with Brithenig). The ideal solution, though, is to have an actual orthography if the language calls for one—and in that case, what would be most useful (if it's possible to achieve with contextual ligatures) is to have the romanization match what you would type to get the correct orthographic form in the font *within reason*. So, for example, if you have two different ways to write [b] (e.g. because one descends from *b and one from *ɓ), it's probably best to eliminate the distinction in the romanization—especially if you call up the other [b] glyph by accessing the capital form of the "b" key. Honestly, when it comes to romanization, I think the whole thing can best be conceptualized with an Optimality Theory tableau, where your constraints are things like FAITH-PHON (be maximally faithful to the phonology of the language), *DIACRITICS (avoid diacritics), *DIGRAPHS (avoid digraphs), 1P1G (1 phoneme = 1 glyph), *UNICODE (avoid non-ASCII characters), etc. An online program that had all these constraints in them would be best, then you could arrange them as you like and give it candidates, and it'll tell you what the optimally romanized form would be. Like, taking e~ɛ, let's take the latter. Here are some candidates for ɛ: ɛ e é è ë ae If you start ranking these constraints based on whatever preferences you have, you'll see how some of these will be eliminated over others. For example, if *DIGRAPHS is ranked highly, "ae" will lose out early. If *DIACRITICS is ranked highly, though, "e", "ɛ" and "ae" will pull through over the others. If you allow for diacritics but take recognizability as a highly ranked constraint, I think both "e" and "è" would clearly win out over "ë" for [ɛ]. Unfortunately for that constraint to work we'd need a pretty thorough survey of natural language romanization systems, but I'm pretty sure "è" is always going to be a more optimal candidate for [ɛ] than "ë" unless something is blocking it (e.g. a tone language that marks low tones). In essence, though, I really think that designing a romanization system (unless it's a fictional altlang that uses a romanization system for its orthography as a part of its conhistory) should be entirely clinical—to the point that it would be great if they could simply be auto-generated. IPA is great as a default, though, because if worse comes to worse, it will be decodable. A rogue romanization system may not be. David Peterson LCS President [log in to unmask] www.conlang.org On Jan 13, 2014, at 6:04 PM, Nathan Klassen <[log in to unmask]> wrote: > On 2014-01-13 5:30 PM, "David Peterson" <[log in to unmask]> wrote: >> >> Please no. > > Why ever not? Seems like a not unreasonable use of a diaresis.