Extension talk:WikiHiero/Archive 02

I've been working on a plugin to replace the images, because they are usually quite unattractive, slightly missized, not-transparent and uncoloured. I have something like 60 or so of the ligatures and rare glyphs to find sources for or write code to generate

... in any case i now have tool chain to generate a complete set of images from a few types of source. (it will not let me post a link) but its on github as wikihiero-image-generator

i'm wondering if this might help make progress in properly replacing the images.

i've used this to create a browser plugin (i can not yet post a link) but its on github as beautiful-hieroglyphs

i also currently have a prototype working from font and from svg although - the svg pipeline is awful though and invokes inkscape, and i have a few bugs to fix in the font pipeline

i've taken care about licenses although i want to follow up to ensure that every author down the chain did the same, but afaik everything here is under a GPLv3, GPL documentation or a less restrictive but compatible license.

---

someone mentioned noto sans before. i have generated images from this but there are a ton of problems. including tofu. they will not fix this tofu on ideological grounds. i'm not sure i want to recommend anyone use a product from people with that kind of attitude.

---

i'm also curious about the choices of images made for certain combinations, since they seem to be... in some case undesirable, and in a few look like spelling mistakes (although i am not very experienced in writing egyptian or hieroglyphs). the r next to the r, and the various cases of ir seem to use the wrong glyph D6 instead of D4

I now have been able to generate the images from the New Gardiner font which is available under the OFL 1.1 and does not have the missing glyph issues found in Noto Sans or Segoe UI.

https://mjn.host.cs.st-andrews.ac.uk/egyptian/fonts/newgardiner.html

What do we do from here? Should I fork the github and make a pull request?

Did you fork it?

I'd like to be able to work with you on this. Specifically, I'd like to implement RTL support for Egyptian Hieroglyphs.

And while we're at at, let's also consider outputting Unicode hieroglyphs instead of images.

Have a look at the related ticket phab:T21T2142324232.

How to I insert hieroglyphs, using the WikiHiero markup, so that I can write paragraphs, like Budge does here, with the glyph employed like a word in the paragraph (no line break)?

Yes, I would second that. I'm using this on Wikisource, for the Enc.Britannica, and would like to keep the characters in-line. Kwamikagami (talk) 20:41, 27 August 2022 (UTC)

can you not simply use a*b*d*t etc...

Been so long I don't remember what exactly I was editing. I'll try to find it.

Ah, this can be accomplished by adding <div> tags around the paragraph (unless it's indented or bulleted, in which case the tags are not necessary) and <span style="display:inline-block"> tags around the hieroglyphs, as explained by @IKhitron: on WP-en.

That works, but is a bit clunky. Would it be possible to simplify the coding to something like <hiero|inline=yes>?

It is very clunky.

it is extremely hard to work out what is wanted here. its not described precisely enough to expect anyone to implement it, and the example given is a book, rather than its content.

Sorry about that. IKhitron's solution is given in the intro to en:Help:WikiHiero syntax, where we give the following sample formatting,

<div>[[Aleph]] is thought to be derived from the West Semitic word for "[[ox]]", and its shape is ultimately based on a [[Egyptian hieroglyphs|hieroglyph]] depicting an ox's head, <span style="display:inline-block"><hiero>F1</hiero></span>, in Egyptian reading a [[Egyptian biliteral signs|biliteral sign]] with the phonetic value {{lang|egy-Latn|ı͗ḥ}}.</div>

which produces:

Aleph is thought to be derived from the West Semitic word for "ox", and its shape is ultimately based on a hieroglyph depicting an ox's head, , in Egyptian reading a biliteral sign with the phonetic value ı͗ḥ.

---

Instead of <span style="display:inline-block"><hiero> ... </hiero></span>, it would be nice to have something less clunky, such as maybe <hiero inline=""> ... </hiero> (or whatever is convenient on this end).

> IKhitron's solution is given in the intro...

Yap, found it there after already found it by myself.

cool. thanks, i see exactly what you mean now.

it is unfortunate that the positioning of the glyph comes out so poorly

Well, to start with, I didn't know how to embed it in text at all. Everything required a separate line. With IKhitron's solution I can now embed hieroglyphs. It's just not elegant, but at least it's possible.

the difference between the appearance in context, and on the thread here is probably a bug.

This would allow people to copy and paste the text. The spatial orientation would be lost if they did so, but at least they would capture the identities of the characters, which is the most important thing. Currently the Gardiner numbers get copied. Those are great as pop-ups while reading, but we can have both, as the 'alt' and 'caption' texts. Kwamikagami (talk) 20:51, 27 August 2022 (UTC)

i am working on a browser plugin which replaces the images ... i could add an option for this too or make a standalone plugin. would that be an acceptable solution?

I think so. Personally, I think it should be the default. An editor could choose to provide only the Gardiner numbers as we currently do, though I can't think of a reason one would want to.

the are useful when using reference based on them... i have found them useful myself.

i will however look into this.

If we could have the Gardiner number as the default for either 'alt' or 'caption', and the Unicode character as the default for the other, so you could make references based on the Gardiner number but cut-and-paste will capture the Unicode character, I think that would be ideal.

i'll add something to the plugin that makes all of the options possible, but leaves it alone by default.

i don't plan on looking at this until i finish replacing the images, of which i have about 60 or so cases to address, which is likely to take a few weeks given that i am working on this in my spare time only, and have two jobs.

Great fan of this! I've been using it with great enthusiasm on wiktionary.

I'm very much looking forward to the implementation of rotation, however, because right now it is impossible to depict the determinative

rotated 90degrees anticlockwise, which is probably its most common orientation.

As Y1 is among the most common determinatives (It's used to indicate abstract concepts), this is a bit of an issue. I was wondering whether it might be possible to insert a pre-rotated version of Y1 into the code (as Y99, say), at least until rotation is up and running?
Once again, my esteem for this system is enormously high - Egyptian would be impossible on wiktionary without it.
Furius (talk) 10:08, 4 October 2012 (UTC)

Y1 rotated by 90 degrees is available as Y1V.

Ah, I gave up on that. It's "Y1a" in Gardiner, so could support for that code be added? Kwamikagami (talk) 20:43, 27 August 2022 (UTC)

I added a note about this to Help:WikiHiero syntax on WP-en.

Ancient Egyptian hieroglyphs could be written from left-to-right as well as from right-to-left.

Currently, WikiHiero supports only producing LTR hieroglyphs.

Having it able to produce RTL hieroglyphs would make them more suitable for inclusion in wikis in languages written from right to left, such as Arabic, Farsi, etc, where they will have the same reading direction as the main body text.

There exist a ticket for this in Phabricator.

I'm not sure that they should be the "same reading direction as the main body text", but it should be possible for them to have direction independent of the main body text, so that the same group of hieroglyphs looks the same whichever language you are describing them with.

It's not obligatory, of course. But it should be made possible in my opinion. It's more natural for the hieroglyphs to be in the reading direction of the text describing them.

There are two distinct cases here: specific instances of hieroglyphs being studied and described, i.e verbatim copies of inscriptions on walls or papyrus, statues, etc. In this case it should be possible to duplicate the original direction of the text for it to be verbatim and to match accompanying photographs, for instance. Which leads to: It would be great to be able to have vertical hieroglyphs too.

The other case is hieroglyphic compositions made up to be used as exemplary of the language or where their archaeological context is not relevant, in which case the directionality is arbitrary.

However, in the second case there is no reason the directionality must match that of text in another language -- language-Wikipedias are independent -- and in general why should the unified directionality be left-to-right? I mean other than this being the capability of the software currently.

Nice feature.

I learnt that the extension will mirror asymmetric glyphs if suffixed by \ backslash:

• <hiero>G11</hiero>
• <hiero>G11\</hiero>

However, en:Help:WikiHiero syntax is lacking this information.

Fun fact: Mirroring works in Project:Sandbox of this wiki and on regular pages, but not in this discussion environment.

Source: German Wikipedia

Are there any plans to render hieroglyph images as SVG? The generated bitmaps are very low-res and look pixelated.

There are no plans. The current set is from 2004 and made by S. Rosmorduc, G. Watson, J. Hirst who licensed it as GFDL. If someone has a newer set of SVGs that is properly licensed, they can probably be replaced quite easily.

There is a set from JSesh which has a GPL compatible license, maybe this could be used?

I created https://phabricator.wikimedia.org/T214232

Thanks!

So, can we update it to SVG?

Doesn't seem like it. There are no good vectored versions of the original hieroglyphs and the available font designs out there don't really seem to map well to the hieroglyph definitions we have currently, so it's a huge effort to deploy that without breaking lots of content.

Whats wrong with Noto Sans? https://fonts.google.com/noto/specimen/Noto+Sans+Egyptian+Hieroglyphs

"don't really seem to map well to the hieroglyph definitions we have currently, so it's a huge effort to deploy that without breaking lots of content."

Was it even tested? How can it break anything? It is just replacing .png image with .svg image with same size. If that breaks anything then better .png can be used. I compared current WikiHiero with Noto Sans font here:https://i.imgur.com/dVW83Sb.png - looks fine to me.

someone tried to map unicode to our glyphs here: https://en.wiktionary.org/wiki/User:Vorziblix/Mismatches_between_WikiHiero,_Hieroglyphica,_and_Unicode

SVG support would be the best solution in my opinion, but at least replacing these old rough images by clean .png, for example by rasterising a free font like Noto Sans, would be clear progress. Where are the current images stored?

I would like to make another extension like this for a different script. Is there a walk through or something else I could follow? Vapblack (talk) 04:45, 26 October 2020 (UTC)

Which script? And what programming languages are you familiar with? @Vapblack:

Its a script that was invented by a dude in the Caribbean in the 90's. There's very little information about it on the internet, but I like it and would like to implement it into my wiki. I'm not really familiar with any programming languages.

Interesting, I'd love to hear more. I like conscripts. Anyway, I was just asking to see if the script had similar combining rules as ancient Egyptian, and how comfortable you would be tweaking the extension code (mirrored at https://github.com/wikimedia/mediawiki-extensions-wikihiero). I'm afraid I don't have a guide for you, but it might be the sort of thing that could be accomplished through swapping out source images, and figuring out how to deal with any essential differences as they are encountered, one at a time.

Swapping out the images 🤔🤔🤔 so easy, a cave man could do it. I think I might give it a go. There's a couple obscure scripts that I would like to implement.

I'm tring to handle the text of hiero as a variable that send to a template or to have in Wikidata as a information.

• If I hold the info in WD with hiero tag's, when get I receive all the content as a text and the hiero tags doesn't act.
• If I hold just the text and, after get it, I put it between the hiero tag, it acts before expand the variable. So, the final result is something like <hiero>{{{1|}}}</hiero> or <hiero>{{#invoke:Wikidata| .....}}</hiero>

I tried to have a template just with a <hiero> to avoid write the tag before variable and allow the expansion, like: {{hiero}}{{{1|}}}</hiero>. In this case the result is: <hiero>i-mn:n:U6-G40:D37-W1</hiero> without execute the hiero tag.

How should I manage it ?

You can't pass content into a tag extension like that (except for very rare examples like Cite), sorry.

Thanks. Does somebody is thinking in hold this information (in another format, perhaps) in wikidata ?. thanks a lot

I think you can use Unicode to represent hieroglyphics nowadays, but I don't think font support is widely available. :-(

OK. I'll study this way.

With the Mayan hieroglyphs script and Aztec Pictographs being proposed to Unicode (00014000-00015FFF Other large scripts) could WikiHiero be duplicated into WikiHieroMaya and/or also WikiHeiroAztec ?

• IMHO The Mayan font proposal is farther along but has missed the Unicode 6.1(draft);
  • George Douros has created a font mapped to a private use area.
  • otaka-san has started a project on SourceForge.net to map it to Unicode.

This post was posted by Peachey88, but signed as Chief Mike.

Hello,

I've just upgraded to MW1.24 and am now getting the error:
Fatal error: Class 'MWInit' not found in .../extensions/wikihiero/wikihiero.php on line 71
That line reads; $wgCompiledFiles[] = MWInit::extCompiledPath( 'wikihiero/data/tables.php' );

I'm not versed in php, could someone enlighten me as to how to repair this please?
Thankyou

All set. While the version page showed Wikihiero 1.0 was installed, the correct version is 1.0alpha2.