Msh210

I thought you might be interested in Tom's recommendation at User talk:Positivesigner, "... assign Sign Writing pictographs for each [symbol in his sign jotting system]. The lookup would be visual enough to not even need to know English and it would be general enough to isolate a group of similar signs in a few steps. My code would not be seen except by the computer programs we use to create the slightly-inaccurate Sign Writing indicies. Once the entry is located, you can have it translated from a video to Sign Writing, PSE, and English."

I'm excited about the possibility of creating a useable index, as the current system still doesn't seem terribly easy to maintain or even to navigate. Your feedback is welcome. —Rod (A. Smith) 18:41, 13 April 2009 (UTC)Reply

Why use the current system for the index? If we're switching to ASLSJ, do so for the index, too. Or am I missing something? In any event, I think that since SignWriting (the real thing, not our version) will, I hope, be Unicode characters, we'll be switching over anyway, so any current system is temporary and need not be ideal; so we might as well leave it the way it is for now even if we do think ASLSJ is better.—msh210℠ 18:47, 13 April 2009 (UTC)Reply

No, I don't think a full conversion to ASLSJ (temporary or otherwise) is on the table, because it doesn't seem to solve any problems of the current transcription system. Tom's recommendation was to combine SignWriting symbols with ASLSJ just to organize (and automatically maintain) our sign language indices. I'm sketchy on the details, but presumably the reorganized index would make it easier for a reader to find the entry for a sign of unknown meaning. I told him to be bold with one or two of the existing Index:American Sign Language pages, so we can at least see how his vision might unfold.

Browsing around the Internet, I cannot find any new information on the integration of SignWriting into Unicode. The layout issues seem so much more complex than Unicode combining characters can accomodate, so I suspect it will be several years, at least. —Rod (A. Smith) 20:37, 13 April 2009 (UTC)Reply

I have a working solution for encoding Binary SignWriting to Unicode. Binary SignWriting uses sequential 16 bit codes to represent the spatial information needed for SignWriting. You can read about the plane 4 solution. You can view the Hello world. page. You can view the BSW JavaScript library (see function char2unicode). I'm currently rewriting the SignWriting Image Server to use Binary SignWriting rather than comma delimited data. It should be ready next week. -Steve 12:49, 08 May 2009 (UTC)Reply

SignWriting Image Server beta 5 has been released to view and download. Section 3 has the Binary SignWriting definition with ABNF for data and Regular Expressions for tokens. -Steve 19:35, 21 May 2009 (UTC)

I am wondering how many places need updated when I add a new entry to the ASL terms on Wiktionary. It seems the term ASE-RED (insert super-long entry title here) was automatically added to and has links at the bottom of the page to Category:American_Sign_Language_adjectives and Category:ase:Colors. But it had to be manually added to American Sign Language gloss term RED and American Sign Language index 1-handshape.

I apologize that I do not understand the Wikipedia-style templates very well. Do you know if there is a way to have these extra places automatically updated to include new entries?— This unsigned comment was added by Positivesigner (talk • contribs).

@Positivesigner, I imagine that that should be doable by a bot, but I can't do it myself. Perhaps someone can help at [[WT:GP]].​—msh210℠ 00:26, 5 March 2017 (UTC)Reply

You mentioned that someone who doesn't know how to correctly title a page may put it under the "sign gloss" namespace. I feel that I could create a title for a sign-word page. But that does not necessarily make my title "correct." Is it first come, first serve? If someone feels it doesn't match the existing pattern, does that make it wrong? If I feel the pattern is wrong, how would I get a change approved?

I currently don't see how the phoneme / hold-move structures are helping to accomplish the overall goal of being able to "lookup the correct spelling or meaning" of a sign-word in a two-dimensional medium. Indeed, the goal of an orthography is to ease the flow of thought from mind to paper and paper to mind. Does the entry "A@InsideShoulderhigh-PalmBack-FlatB@NearCenterChesthigh-PalmDown Frontandback" help anyone to do that? If a new signer sees a person speaking in ASL, is there any chance they could "sound out" the spelling to find the meaning if they don't understand about the spacial aspect of ASL grammar?

My biggest problem is that I don't know anyone to talk to about some different ideas I have for these issues, or to whom I can express my concerns. I was e-mailing Rodasmith regularly at the end of 2009, but he told me that he had some better things to do. So that's why I'm writing to you here. Thank you for your patience. - Positivesigner 03:06, 13 April 2011 (UTC)Reply

Regarding your first point, we need canonical page titles. There's some discussion about this at [[User talk:Rodasmith#another ase entry, and some ramblings about dimensionality]]: what directions can be assumed and not included in titles. If we're keeping our current page-title system, this should be codified.

By the way, as discussed in the past somewhere, if and when SignWriting is included in Unicode, all the entries should be moved to SignWriting titles.

You're 100% right that it's very hard to find an entry by looking it up directly; as you know better than I, [[Index:American Sign Language]] is meant to ease looking up entries. Note incidentally that the difficulty of looking up a word one hears is not limited to sign languages; a Soundex-like search mechanism would be a wonderful addition to this site.

No one to talk with is a function of there being no ASL (or other SL) editors. If you have a specific idea you want implemented, I suggest you raise it at [[Wiktionary talk:About sign languages]] and point to it with a heads-up at the talkpages of the various SL editors (Rodasmith, Di gama, ECUgrad96, Neskaya, me, perhaps others); even absent editors might have an e-mailed notification in place for edits to their talkpages. Seeing support there, implement it; or, seeing no opposition, bring it to the Beer parlour. I think that'd usually be a good way to do it. If what you have is not a specific idea to be implemented but a concern to be discussed, then, again, bring it to [[Wiktionary talk:About sign languages]] with links from editors' talkpages. I don't know what else to tell you, I'm afraid; there just isn't much of a community of SL editors here (to put it mildly).​—msh210℠ 08:07, 13 April 2011 (UTC)Reply

Or just being it straight to the BP, bypassing the SL talkpage, perhaps. Few people will care, and it will clutter up an already cluttered BP, but at least more people will notice it.​—msh210℠ 16:12, 13 April 2011 (UTC)Reply

Hi there. I see you are a mathematician. There are lots of difficult maths words in Category:Citations of undefined terms - ((deprecated template usage) autoconvolution, (deprecated template usage) biorthonormal, (deprecated template usage) coinvariant and so on). It would be good if you could shed some light on any of them. Cheers. SemperBlotto (talk) 08:19, 3 December 2012 (UTC)Reply

There are also a few mathematical terms to be found at User:Metaknowledge/Todo, like position vector and θ-intercept, although I daresay I could define those (but not without fear of having forgotten my geometry and thus of making a definitional error). —Μετάknowledge^{discuss/deeds} 04:51, 4 December 2012 (UTC)Reply

I know of an SOP meaning, and of no non-SOP meaning, of position vector; same for θ-intercept. I can look at the two lists mentioned; thanks for the links. Any way the math terms from the undefined-but-cited list can be listed separately? (Not sure how that can be done: is there some criterion that marks them, like a citation from the arXiv or a particular editor?)​—msh210℠ 06:24, 4 December 2012 (UTC)Reply

Well, we do have (deprecated template usage) x-intercept, you can RFD it if you like. Similarly, "position vector" is about as SOP as (deprecated template usage) unit vector, IMO. —Μετάknowledge^{discuss/deeds} 06:26, 4 December 2012 (UTC)Reply

Yeah, x-intercept is IMO SOP also. As for unit vector, that's a vector with unit length, not at all clear IMO from the parts; position vector OTOH is a vector that signifies/marks a position.​—msh210℠ 07:14, 4 December 2012 (UTC)Reply

What, will they get it confused with all those vectors floating around with a direction of 1? What else could it be? —Μετάknowledge^{discuss/deeds} 07:21, 4 December 2012 (UTC)Reply

If someone started talking to me about a "2 vector", I'd have no idea what he meant, and would have to guess it were a vector all of whose components were 2.​—msh210℠ 07:26, 4 December 2012 (UTC)Reply

Thanks for going through my list! (octachoron too?) —Μετάknowledge^{discuss/deeds} 07:04, 4 December 2012 (UTC)Reply

Hm…. I see various online sources and just two bgc books are defining it as a hypercube in four dimensions, and I see no other definition for it, but I'm not sure it's attested. But if it means anything, then I suppose it means that  :-) .​—msh210℠ 07:10, 4 December 2012 (UTC)Reply

(deprecated template usage) N-gon too, if you please. —Μετάknowledge^{discuss/deeds} 19:46, 3 January 2013 (UTC)Reply

Nah, it's SOP: see -gon.​—msh210℠ 00:42, 4 January 2013 (UTC)Reply

But compare [[talk:n-tuple]] and [[talk:n-dimensional]].​—msh210℠ 02:51, 4 January 2013 (UTC)Reply

You wouldn't happen to be able to define "pseudocodeword", would you? - -sche (discuss) 08:13, 15 February 2013 (UTC)Reply

I'm afraid not. It seems to be used in the mathematical theory of error detection/correction, and to be defined in terms of some sort of graph (in the graph-theory sense, not like the graph of a function from analytic geometry) — but that's about all I can say. (It's also sometimes spelled pseudo-codeword, unsurprisingly, and I didn't check which is more common, or was at various times.)​—msh210℠ 18:30, 15 February 2013 (UTC)Reply

see also

• https://bugzilla.wikimedia.org/43652#c7
• http://lxml.de/tutorial.html#event-driven-parsing

-- Jeremyb (talk) 06:20, 12 February 2014 (UTC)Reply

Many thanks.​—msh210℠ 18:33, 14 February 2014 (UTC)Reply

I've read a few actual adult books in Hebrew now (as opposed to just newspaper articles and whatnot), and I've found that a number of things I'd thought were archaic, because I only knew them from the liturgy, do actually occur in formal-but-not-archaizing Modern writing. For example, you asked about nitpa'el once, and I recently came across a real example, on page 173 of Memories After My Death, Yair Lapid's first-person biography of his father Tommy Lapid. After mentioning that Abba Eben was going to a secret meeting in Argentina, he explains why; he states that relations between Israel and Argentina were tense at the time, due to the abduction of Adolf Eichmann, and writes:

אבן, שכיהן כסגן ראש הממשלה, נתבקש לגייס את יוקרתו הבינלאומית הידועה כדי לפתור את המשבר.

I do still think it must be pretty rare, though, firstly because I think this is the only Modern example I've come across, and secondly because after you brought up nitpa'el, I asked my father about it, giving some forms listed in my dictionaries, and he said that he would only understand those forms as 1p future, never as 3ms past. (I'm sure that he actually would have understood them in context, but he didn't recognize them on their own.)

—Ruakh_TALK 07:56, 25 February 2014 (UTC)Reply

Thanks for the info. I don't think this changes AHE policy at all, though; do you?​—msh210℠ 15:52, 25 February 2014 (UTC)Reply

I haven't looked; I'll take your word for it. The purpose of my comment here was merely to correct something that I think I once told you and that I now think was mistaken. (Oh, and to provide a possible quotation, if one would be useful.) If this correction results in an en.wikt policy improvement, then great; if no such improvement is needed, also great. —Ruakh_TALK 07:58, 26 February 2014 (UTC)Reply

Incidentally, while I have your ear eye: FYI, I've just RFVed a sense you added.​—msh210℠ 15:57, 25 February 2014 (UTC)Reply

Just thought I should mention that I recently accidentally came across an article titled “Developments in the Hebrew verbal system of Israeli children and youth” by Aaron Bar-Adon (1978) and it had this to say about nitpa'el:

nitpaˀel (nitCaCeC) is rare in younger Hebrew, although it is in frequent use in formal Hebrew, and to some extent also in the informal speech of adults. Sometimes one has the impression that the speaers conceive of nitpaˀel (which was originally a variant of hitpaˀel, under the impact of Aramaic, since the time of Mishnaic Hebrew) as a ‘combination’ of nifˀal and hitpaˀel, as if to enhance the passivity of hitpaˀel (which, as mentioned above, is now taken to be mainly a reflexive and reciprocal binyan, while originally it did have the passive meaning!). Thus, in hitka(b)bed ‘he honored himself; he had the honor; he was honored’, some speakers perceive more the first one or two meanings, while in nitka(b)bed they will perceive more exclusively the last connotation, ‘he was honored’, in the passive. At any rate, nitpaˀel has so far been rare in younger Hebrew. One would expect some productivity in that area too.

--WikiTiki89 17:34, 25 February 2014 (UTC)Reply

Interesting; thanks. AHE says we treat it as a separate entry if its meaning differs from the hitpael. Apparently, that's most often true — at least according to Bar-Adon.​—msh210℠ 22:54, 25 February 2014 (UTC)Reply

I don't know if you can say that the meaning "differs", they just have different connotations. I think the definitions in the entry for הִתְכַּבֵּד, based on Bar-Adon's definitions should look like this:

1. (usually hitpa'el) he honored himself
2. (usually hitpa'el) he had the honor
3. (usually nitpa'el) he was honored

Splitting the definitions onto separate pages will make it harder to convey this information. --WikiTiki89 06:10, 26 February 2014 (UTC)Reply

Hi,

I realise Hebrew can't be transliterated 100%, even with vowel marks but which one is incorrect - Module:he-translit or WT:HE TR? Maybe one or the other should be fixed or both? --Anatoli ^{(обсудить}/^вклад) 06:25, 16 April 2014 (UTC)Reply

@Atitarev Can you point out where you see a problem? --WikiTiki89 20:12, 16 April 2014 (UTC)Reply

I'm not aware of the problem. I'm referring to the maintenance notice on the module. --Anatoli ^{(обсудить}/^вклад) 20:22, 16 April 2014 (UTC)Reply

Nothing is "incorrect". The module simply cannot transliterate words that have ambiguous letters or vowels, or lack vowels entirely. The consensus thing is less of a problem, since even though there is no consensus, there is a current common practice. --WikiTiki89 21:05, 16 April 2014 (UTC)Reply

OK. So, you agree with the wording of the maintenance notice? --Anatoli ^{(обсудить}/^вклад) 21:45, 16 April 2014 (UTC)Reply

I personally don't, but I don't care about it that much, as long as the module is not used until it can somehow be fixed (such as by using separate Unicode characters for the two qamatses). --WikiTiki89 21:50, 16 April 2014 (UTC)Reply

WT:HE TR, even ignoring the 'scholarly' column, is not followed: consensus I think is to transliterate פ as f, which it doesn't seem to indicate, and I don't think anyone transliterates ח as kh. (And there may be more errors, also. Those two jumped out at me.) Module:he-translit copies the latter of those two errors and introduces its own: (a/o) for kamats, which is (pretty much) never ambiguous but always either a or o, and h for ה even word-finally. (And, again, there may be more errors, also. Those two jumped out at me.)​—msh210℠ 04:39, 18 April 2014 (UTC)Reply

The פ error at WT:HE TR was my fault from when I added the scholarly column to the table; I just fixed it now (the scholarly transliteration is actually used in some etymology sections). But "kh" is used for ח quite frequently. I don't think that the "(a/o)" thing implies that any individual kamats is ambiguous, but that a script cannot possibly distinguish them without knowing the morphology of the word; I don't think that "(a/o)" was actually intended to be used as a transliteration, but as an indication that the transliteration is not known by the script. Omitting word-final ה was probably just an oversight in the script and not intended to be a change to the transliteration system. To me, all this is an indication that the Hebrew cannot as of yet be automatically transliterated, and not that the module is flawed. --WikiTiki89 06:55, 18 April 2014 (UTC)Reply

Ping. Fair enough. But the distinction in your last sentence is one without a difference: if Hebrew can't be machine-transliterated, then any script that attempts to do so is automatically flawed.​—msh210℠ 03:42, 25 April 2014 (UTC)Reply

Ping. Oh, and another error in the module is that it doesn't mark stress.​—msh210℠ 05:44, 27 April 2014 (UTC)Reply

Stress and kamatz (a/o) are not errors, it's simply not known for sure. Cyrillic based languages, BTW, use acute accent to mark stress, in Arabic, marking stress has been abandoned, as it is predictable or may differ substantially in dialects and depends on whether ḥarakāt are pronounced (very formal or Qur'anic Arabic) or not. The purpose of this and similar modules would be to transliterate as close as possible and match WT:HE TR to the maximum, in cases when people are not familiar with the script and no manual transliteration is provided. Any omissions were not intentional. I prefer "kh" for ח, as "ch" is misleading and it seems that "kh" is used quite often here and elsewhere. Any missing characters should be added to the module and for (a/o) we could use a default "a", a more common reading, which could be manually replaced with "o", same with other ambiguous cases. Please consider creating "{{he-xlit}}" (with a disclaimer). If we have an approximate pronunciation tool, it would be easier to find the correct one. --Anatoli ^{(обсудить}/^вклад) 06:35, 27 April 2014 (UTC)Reply

Unlike in Arabic, in Hebrew stress is phonemic. Usually it can be determined from the vowels, but not always; consider the minimal pair בָּנוּ (bánu, “in us”) vs בָּנוּ (banú, “they built”). And stress of borrowed words is all over the place in Modern Hebrew. --WikiTiki89 18:39, 27 April 2014 (UTC)Reply

I understand this. Stress is another thing that has to be done manually. Still, "banu" (without a stress indication is better than no transliteration at all, don't you think? --Anatoli ^{(обсудить}/^вклад) 22:28, 27 April 2014 (UTC)Reply

Yes, but "b(a/o)nu" is not. --WikiTiki89 22:34, 27 April 2014 (UTC)Reply

I tried to explain the usefulness of such a (automated) transliteration method below. I'm not suggesting to use it in the main space. However, if one sees "b(a/o)nu", a person (like me) may search for "banu", "bonu" and find the right transliteration. Especially if one knows that most likely it's "banu", not "bonu". I have transliterated a number of Hebrew words that way in the past - found basic letters, then searched and edited (can't remember the exact words). User:ZxxZxxZ seems to agree with this or has a similar opinion. I can now transliterate with some level of certainty ביומטריה - "biyomet'riyah" (?) (do you think it's better than nothing?). Finding forms with all vowels always helps (I found בִּיּוֹמֶטְרִיָּה on Hebrew Wiktionary). I'm not actively working with Hebrew and not learning it but I don't like so many words having no transliteration. Does it make sense? I know some people will say - don't touch Hebrew entries, if you don't speak it. I don't hold such views for editing in any language - mistakes do happen, someone may correct them. If an editor makes a lot of mistakes, he/she should stay away and learn. I'm very thorough with languages I don't know or don't know well and I welcome any corrections - everything I edit is on my watchlist (huge). --Anatoli ^{(обсудить}/^вклад) 23:11, 27 April 2014 (UTC)Reply

One counterpoint is that it is much easier to find and fix entries that don't have transliterations than it is to find and fix entries with incorrect transliterations. But I agree that you don't have to know a language to do basic editing in it. Just to point out one mistake I've seen you make: words in the construct state almost always have internal vowel changes (unlike Arabic where only in rare cases the last vowel changes, ignoring the loss of nunation), for example דָּבָר (davár) > דְּבַר (d'vár). So be careful when transliterating or adding vowels to compound words. --WikiTiki89 23:27, 27 April 2014 (UTC)Reply

Thank you. Yes, that's a valid point. --Anatoli ^{(обсудить}/^вклад) 00:14, 28 April 2014 (UTC)Reply

Re "I'm not suggesting to use it in the main space": where, then? By the way, a kamats is always a except before a dagesh or sh'va or maqaf or mater lectionis + maqaf or word-final unvowelized non-mater: only before one of those is it ambiguous. I assume Lua can capture that? In any event, I think a transliteration with "(a/o)" is awful in any public-facing (i.e. content) namespace.​—msh210℠ 06:54, 28 April 2014 (UTC)Reply

I think there are more exceptions, and it would be impractical to take them all into account. For example שָׁרָשִׁים is an alternative of שֳׁרָשִׁים (also, can you give an example of "mater lectionis + maqaf"; I'm not sure what you mean). --WikiTiki89 07:19, 28 April 2014 (UTC)Reply

I think the first kamats in שָׁרָשִׁים is disputed a/o (and, funnily enough, this might be the one reasonable use of "(a/o)" in a translit  :-) ), but I take your point. Re mater lectionis + maqaf, see e.g. בראשית ל א, havo-li.​—msh210℠ 07:34, 28 April 2014 (UTC)Reply

I always thought that הָבָה־לִּי is háva-li, with the doubling of the ל being similar to the doubling of the מ in לָמָּה (láma). --WikiTiki89 16:09, 28 April 2014 (UTC)Reply

Here's what I mean. Current entry @בִּיּוֹמֶטְרִיָּה doesn't provide transliteration or vowelisation. By using the translit module I can see it's something like "biyomet'riy(a/o)h". It's obviously "biyomet'riyah", at which one can arrive using a translit module. --Anatoli ^{(обсудить}/^вклад) 06:53, 27 April 2014 (UTC)Reply

Actually it's biyométriya (sh'va nakh after the tet, no mapik in the hei). —Ruakh_TALK 05:28, 17 June 2014 (UTC)Reply

This is an improvement for words starting with bet, kaf, or pei, but I'm not sure it works for words starting with gimel, dalet, or tav.

(I guess that problem was already there in the subsequent sentence, but I either didn't notice or didn't remember it till now.)

Should we have two separate templates? Or maybe the template should take the actual first letter as an argument, and do some intelligent stuff accordingly?

—Ruakh_TALK 04:55, 17 June 2014 (UTC)Reply

Re your first paragraph: Oh. Oops. Right. Thanks for catching that. But the truth is that I think my most recent edit was in error and the "modern texts" was correct the first time, since such modern texts as include vowels (kids' books and liturgy and maybe poetry(?)) follows that rule. I'm rolling back. But feel free to disagree and to unrollback. But you're right, certainly, that the remaining instance of "modern speech" is misrepresentative of modern pronunciation for three of the consonants.

Re your last: I like your second idea better. It can default IMO to {{padleft:|1|{{PAGENAME}}}} (if PAGENAME is parsed before padleft).​—msh210℠ 05:29, 17 June 2014 (UTC)Reply

Ping.​—msh210℠ 05:16, 24 June 2014 (UTC)Reply

Sounds good. Is it all right with you if I put that logic in a module? It's unwieldy to make a lot of references to {{{initial|{{padleft:|1|{{PAGENAME}}}}}}}.
Re: "if PAGENAME is parsed before padleft": I imagine that the parsing proper happens in a single pass, and the evaluation/expansion mostly seems to follow a sort of call-by-name strategy that makes it hard to say what happens "before" what, but yes: {{padleft:|1|{{PAGENAME}}}} evaluates to the first character of the page-name.
—Ruakh_TALK 06:11, 24 June 2014 (UTC)Reply

Certainly (in answer to your question).​—msh210℠ 06:23, 24 June 2014 (UTC)Reply

Hi! Do you know how to define any of the various math terms in Category:Requests for definitions in English entries, like semiabelian, semicalibrated, semicanonical etc, quasibialgebra etc, or subriemannian etc? (In some cases it seems like "Partially ___" or "Having some of the characteristics of being ___" seems like it might cover it.) - -sche (discuss) 23:25, 7 February 2019 (UTC)Reply

I hope to check out that list when I have a chance. For now, just a note about semiabelian. It doesn't merely mean "somewhat abelian" in any which way: rather, there's a specific sense in which the object so described is somewhat abelian.​—msh210℠ 05:24, 10 February 2019 (UTC)Reply

Can you point me to the discussion that led to this edit (12:35, 1 February 2010.)? Brett (talk) 02:15, 26 November 2023 (UTC) ːNevermind, I've tracked it down. Sorry to bother youǃ--Brett (talk) 14:21, 26 November 2023 (UTC)Reply

In case anyone else is reading this and wondering, it's Wiktionary:Tea room/2010/January#going_on.​—msh210℠ 18:01, 26 November 2023 (UTC)Reply

Hi! I'm looking to make a few changes to Template:RQ:Tanach to add support for |passage= and |translation= parameters and I wanted to solicit your feedback as the original creator before inadvertently making any controversial changes. In short, I'd like to:

• rename |t= to |tsrc= so that |t= can be used for the translation text and not the translation source. (I have a bot that can do this easily)
• convert the template to use Module:quote for formatting and param handling

  This will have a minor effect on this display so that

  {{RQ:Tanach|1|2|3–4|t=JPS}}

  which currently displays as:

  Tanach, Genesis 2:3–4:

  (please add the primary text of this quotation)

  JPS

  Lua error in Module:debug at line 160: 't' parameter has been renamed to 'tsrc'
  

  using Module:quote would display as:

  Genesis, 2:3-4, with translation of the Jewish Publication Society:

  (note the , between Genesis and 2:3-4, this format is shared by Template:RQ:Quran)

  or

  Tanakh, Genesis 2:3-4, with translation of the Jewish Publication Society:

  (using the book name, we can remove the , between Genesis and 2:3-4, this format is used by Template:RQ:KJV)

• There's a comment at Template_talk:RQ:Tanach that suggests renaming the template from "Tanach" to "Tanakh" - if this is something that would be of value, I could make this change at the same time the bot renames t= to tsrc=.

Do you have a preference for format option 1 or 2? Should the template (and the book name, if used) be "Tanach" or "Tanakh"? Thanks! JeffDoozan (talk) 15:48, 31 January 2024 (UTC)Reply

I'm much less active here than I used to be, and my reply to you (a) is based on what you wrote here (I have no other knowledge of the module in question, for example), and (b) should be taken as the opinion of such a person (i.e., don't put too much weight on it).

I prefer Tanakh if there must be a comma: a comma after the Bible book name looks terrible. Better still would be no comma and no Tanakh: can the module be modified to make the comma optional? Or of course don't switch to using the module: not only the simplest solution, it also doesn't ruin the formatting or require a module edit so is the best solution.

Personally I use the spelling Tanach but Tanakh is I think much more common especially in academic circles, so if one or the other has to display then it should be Tanakh. The template can be named whatever and have a redirect from the other so people can use either.​—msh210℠ 21:11, 31 January 2024 (UTC)Reply

Are you sure this is a word? It's just a few conversations and not books? Citations:rereconsider Heyandwhoa (talk) 23:06, 4 February 2024 (UTC)Reply

Nah. If I were sure it's a word, I'd probably make an entry. It's a citations page, which AFAIK has a much lower bar for inclusion.​—msh210℠ 06:48, 5 February 2024 (UTC)Reply