Template talk:List of hieroglyphs

Development (Feb 2021)
Feb 2021:


 * checked old==new rows DePiep (talk) 01:11, 28 February 2021 (UTC)
 * Each Gardiner ID is an anchor: (or   &rarr; ).
 * From outside: Template:List of hieroglyphs (or ); use article name later on
 * todo: unicode cp: rm U+ prefix = editor-friendly


 * List of Egyptian hieroglyphs
 * List of hieroglyphs/row
 * List of hieroglyphs/doc

-DePiep (talk) 01:51, 28 February 2021 (UTC)


 * version before template conversion.
 * Note the elaborate setup.  -DePiep (talk) 01:58, 28 February 2021 (UTC)


 * As of March 15. By now, the table has these features & changes, coming from the flat table (See also Template /doc):


 * Input is by parameters into the /row-template; formatting (e.g. fonts, into columns) is done by the /row-template.
 * Some parameters: ....
 * Subheaders are added per Gardiner class, roughly A–Z, NU, NL, Aa. There is a corresponding TOC template available (with links active, so clicking "P" in the TOC jumps to section P).
 * Transliterations now presented in rows, using indexed parameter (tl1= tl2= tl3= ...) an Unbulleted list
 * Internal wikilinks are introduced (writing  in input creates in-page wikilink to hieroglyph C3). The same anchor can also be used from another page: , or use slink.
 * Text cleanup: rm unneeded newlines, more consistent ucfirst and punctuation in note,


 * Todo, planned:
 * Put phonetic from column Transliteration into column Phonetic.
 * Add more subrow usage (at least, translit and phonetics should have equal subrows)
 * Add Wikidata QID value (at least for documentation reason)
 * Given the list of, add those wikilinks systematically in the big table (but in which column, and which form?).
 * Rethink usage of boldface.
 * Add legend/clarification for deterministic, uni/bi/triliteral and maybe add extra column for these.


 * These plans required editors-input, because I'm not familiar with hieroglyphs' definitions and Talk:List of Egyptian hieroglyphs has multiple serious complaints about current (2019–) status of the table. Could be done in a few weeks, I thought...
 * Alas, then came User:Rhemmiel and introduced me to the TLS Face-surprise.svg ;-)
 * Development talks: continued below. -DePiep (talk) 15:20, 16 March 2021 (UTC)

Sign functions
This is amazing work, thank you for all the effort you're putting in! I’m no good at templates, but would you be able to add parameters for the multiple functions of each sign? These belong to three classes, conventionally called determinatives (classifiers), logograms, and phonograms. Every determinative has an associated semantic value, every logogram has an associated phonetic and semantic value, and every phonogram has an associated phonetic value. Any given sign may be used in any of these functions in an indefinite number. Check out the Thot Sign List to see how this is organized, but here’s a quick mockup of what I mean:

Rhemmiel (talk) 08:25, 16 March 2021 (UTC)
 * Right in time! I was preparing questions on how to improve the table, especially since here are some serious criticisms about the table. So now I started reading studying the TSL.
 * First reply: of course we can (and should) build the setup you sketched. I already discovered that a multi-row definition per hieroglyph is required (I am not familiar with hieroglyphs -- yet; I'm from Unicode & table-building).
 * Also, the column headers are clear. -DePiep (talk) 15:28, 16 March 2021 (UTC)


 * Some questions to get familiar.
 * Write "phonemogram" as TSL does?
 * No need for a column "uni/bi/triliteral" noting, possibly also "numerical"?
 * I understand we kan initially start with the Gardiner list (1071). Given their description of Classes, they (and so we) can extend the list, see 2.1, example A6 has A6 - A6A ... A6D (only A6 and A6A are in Gardiner).
 * Also, they mention merging D19 and D20 as being classes. Our table should be ble to note this (still having a complate Gardiner list IMO).
 * When using TSL, we must add their reference I assume (per hieroglyph)
 * For tech purposes, we can use "index 1" ... "index 7" for the (function) subrows we need.
 * No hurry ansewering, I'm just starting thinking about it. (See also next questions about higher level). -DePiep (talk) 16:12, 16 March 2021 (UTC)


 * That's great to hear! As for your questions:
 * 1. The words are identical in meaning although "phonemogram" is a bit peculiar to the TSL. "Phonogram" is more prevalent in Egyptological literature and in general use, as well as being the title of the wiki page for the concept: Phonogram. For these reasons I think we’d be better off using phonogram. This also applies to “determinative” in favor of “classier.”
 * 2. Uni/bi/triliteral is an attributes of signs only in their function as phonograms. So 𓋹 can be used as a triliteral phonogram for ꜥnḫ, 𓄟 as a biliteral phonogram for ms, and 𓄿 as a uniliteral phonogram for ꜣ. It just refers to the number of consonants in a phonogram. It may be of some interest to explicitly indicate when a sign functions as a primary “alphabetical” (uniliteral) phonogram, but I think this can be done under Notes rather than creating an entirely new header. For instance, under the notes for 𓄿 we can put: Uniliteral phonogram for ꜣ (Egyptological alef), and under the notes for 𓂝: Uniliteral phonogram for ꜥ (Egyptological ayin).
 * 3. I think it would be best to start with Gardiner and expand from there, like you said. Some of the signs and variants listed at the TSL are not encoded in Unicode.
 * 4. Agreed.
 * 5. Certainly.
 * 6. I'm not sure about the tech side of things, but I will start reading up to familiarize myself!


 * For a concise overview on the principles of hieroglyphic writing (and maybe also some inspiration for how to handle hieroglyphs on wiki) I’d recommend reading over the Digitale Einführung in die hieroglyphisch-ägyptische Schrift und Sprach, which is very informative and useful for reference.
 * Rhemmiel (talk) 08:38, 17 March 2021 (UTC)
 * Just to inform you, I have been a bit silent in this area last weeks. One cause is that the new TLS table structure you introduced to me :-) and its implications, are quite complicated to implement. Also, when working heavily on scripts & Unicode since January, I stumbled upon loads of improvements deerly needed (such as this hieroglyph table). It is fun, and all the low-hanging fruit is nice working. Currently, I am trying to easily improve infobox Hiero -- not to be confused with Infobox hieroglyphs ;-)
 * Maybe you can take a look at Draft:Thot Sign List and add something? (Personaly, I am figuring to expand their data model). -DePiep (talk) 22:31, 22 March 2021 (UTC)

Useful links

 * TSL thot sign list About (2.1: History, 2.2: Goal, data model, 2.3: Availability, 2.4: Credits)
 * Draft:Thot Sign List


 * Manuel de Codage (Buuurman et al., 1988)
 * Karnak (fr), vocables

Glossary

 * deterministic or  determinative
 * logogram
 * phonogram, phonemogram
 * phonetic value
 * semantic value
 * Draft:Thot Sign List (TSL)
 * function (sign function)
 * Gardiner
 * class (TSL)
 * sign
 * Manuel = Manuel de Codage (Buuurman et al., 1988)
 * vocables = vocables (Karnak (fr))




 * Egyptian uniliteral signs
 * Egyptian biliteral signs
 * Egyptian triliteral signs
 * Egyptian numerals

Set up concepts

 * What would be the best technical setup for such a table? Could be by: Template, Module, or Wikidata
 * By Wikidata:
 * Every hieroglyph (class; gardiner ID) gets its own WD entry (QID). The QID has well-specified properties (Gardiner ID, TSL ID, Descr, multiple functions + phonetic + semantic as a set, references); a Lua-module at enwiki kan read WD and produce the table (or an infobox).
 * Clearly, today Wikidata has no datastructure for hieroglpyphs (at all, let alone for TSL data). See . We'd have to build it (add or find right propoerties there).
 * But ... once in WD, the profits are huge. It is international right away, curating (add, maintain) can be done easily & automated.
 * By Module (Lua):
 * Need to design(/copy ;-) ) the TSL data structure.
 * Data would be in a structured page, systematic to edit.
 * Requires the table-builder module to be build.
 * Great way to have the data systematically together.
 * Data reusable (e.g. for infobox).
 * By Template:
 * Like the table is now.
 * Easy to build, less flex.
 * Data entering not simple, in regular edit screen (many parameters needed, also like func1, func2, ...func7, phon1, ... phon7, sema1, ... sema7).
 * In general:
 * Would be great if the TSL data would be available in file format, for automated entering. Instead of c/p or read/type :-(
 * We could use good texts about all special words used (footnote, article/section, ...).
 * So far for now. -DePiep (talk) 16:39, 16 March 2021 (UTC)