Proposal: version names for Tcekitaujau dialects

From Lojban
Jump to navigation Jump to search

Tcekitaujau is an experimental proposal and family of dialects of Lojban which, when implemented/activated, swaps some cmavo (and rafsi) pairs' with respect to their CLL 1.1 meaning. Unfortunately, there are very many possibilities for which words are swapped. Thus, it is necessary, in order to avoid confusion (and, technically, ambiguity/breaking of the language in any text which employs any of the words which any dialect of Tcekitaujau would swap), to implement naming in order to identify which dialect is in use.

This is done by using "jo'au". This word specifies the Lojban version being activated for thefollowing text (until the next "jo'au" is uttered). The default version, modulo culture and implicit social conventions, is CLL 1.1, which is officially implemented. In order to acivate (some dialect of) Tcekitaujau, utter "jo'au tcekitaujau".

Without any further specification, this implies only that some dialect of Tcekitaujau is being used, not which - it is a vague flag/warning to the audience.

What follows is a series of proposals, possibly mutually contradictory, for how to further specify which dialect, exactly, is being used. Note that if any given dialect is ever incorporated into the default implementation of Lojban (some CLL v. <math>x</math>), then this manual and explicit activation via "jo'au" - for that specific dialect - is automatic and therefore unnecessary.


"kyfy" version naming schema


This is a proposal by lai .krtisfranks. (Hence "kyfy"). It is designed to be inclusive of and general for any dialect of Tcekitaujau. It should be easy to understand, craft, and express; the general principles should be easy to remember. However, it is also clunky and arbitrary, making its practical usage somewhat difficult to memorize.

All versions are specified by "jo'au tcekitaujau kyfy pi'e" which is immediately followed by a number or a QWERTY letter string with letters in standard lerfu form for Lojban (this string is the mode specifier), which may then be immediately followed by "pi'e" and then immediately by a number (this is the tier specifier), which will be immediately followed by "pi'e" and then immediately by some ASCII string or a string of hexadecimal digits (which is called the version specifier). If a tier specifier is used, then both a mode and a version specifier must be used. The whole string is called the specification.

First, there are 2n+1 modes; currently n = 1.

They are currently assigned mode specifiers "0", "1", and ".a'y". Mode ".a'y" is the only one of these which must not have a tier specifier; all of the others requir tier specifiers. Mode ".a'y" is an elliptical version name which just means that some dialect of Tcekitaujau is in usage, but which is not specified; it is, in a sense, equivalent to "xo'ei", except for the fact that no additional strings may be concatenated to its end; ".a'y" as a mode specifier cannot be followed by any nonempty string.

Each version specification literally encodes the swaps as an ordered string of bits; how this works will be explained below. If the mode is "0", then "on" bits are denoted by "0"'s and the "off" bits are denoted by "1"'s - this is exactly opposite to typical computer notation, but it has its perks. If the mode is "1", then the "on" bits are denoted by "1"'s and the "off" bits are denoted by "0"'s - exactly as is standard in computer science. That is for n being 0 or 1, mode "n" has "n" representing "on" bits and its bit-complement representing "off" bits. Thus the version specifications (but not the tier specifications) for modes "0" and "1" are exact bit-complements of each other before rendering/being 'encrypted'.

If two specifications are connected by "ce'o", then they left-group but in cases of conflict, the latter one prevails. They can compound so that if the first-mentioned version swaps X and Y while the latter-mentioned version swaps X and Z such that they do not really conflict, then the swaps happen in left-to-right order so that new-X is old-Z, new-Y is old-X, and new-Z is old-Y. The whole specification must be uttered when "ce'o"-connected.


The version specification is optionally terminated by "boi".

Throughout this section, a swap option will be denoted by "{X, Y}." where X and Y are words or rafsi (in quotes); this means that the old meaning of X is proposed to be the new meaning of Y and that the old meaning of Y is proposed to be the new meaning of X. Note that the ordering of these two words is immaterial: the pairing is symmetric. Nothing else is included in the option other than this swap and each list entry of an option will specify only the swap.

In English, kyfy specifications of Tcekitaujau may be written in the following form "Tcekitaujau kf.[mode].[tier].[version]".

The case of "jo'au tcekitaujau" is the only one in this schema which may refer to any dialect whatsoever of Tcekitau without actually having to list which they are. Every other standard activation which lists a mode activates exactly that specification; any unmentioned specification is inactive. So, "jo'au tcekitaujau kyfy pi'e pa pi'e pa pi'e vaivai" activates Tcekitaujau kf.1.1.FF and nothing else.

Mode and tier specifications are macrodigits which are interpreted as numbers as is standard (base specified by "ju'u'i"); thus, mode "A" (hexadecimal) is the same as mode "10" (decimal).

Each ASCII character in a version specification must be immediately followed by "bu" in all cases, even if the character is standard in Latim-script Lojban. Thus "1" is "pa bu", "a" is ".a'y bu", etc. "q" is ".kop. bu", "w" is ".vel. bu", "h" is ".xet. bu", "k" is "ky bu", "u" is ".u'y bu", "v" is "vy bu", and "'" is ".y'y bu". Capitalization matters. Special characters (including the whitespace) must be specified. ASCII is basic (7F entries).

When ASCII and hexadecimal digits ("A"-"F") are written in English, then each hexadecimal digit is to be immediately preceded by "#". So, a version written as "B#CC#A#A" is version ~"letter-B hexadecimal-C letter-C hexadecimal-A hexadecimal-A". Lojban does not have these difficulties.

In time, some modes or tiers may become defaults and so would not need to be specified explicitly. Some versions may overlap with other "kyfy" versions or be equivalent to other non-"kyfy" versions; this is an intentional feature.

The labels of the immediately following subsections (of form "Tier [#]") specify the tier specification options in order. So, Tcekitaujau kf.1.4 is in the fourth tier of the "kyfy" system (amd in mode "1"), so it deals with scalars and UI modifiers.

Tier 1: cmavo-swapping - the primary/basic dialect

Tier "1" deals with the eponymous words "ce", "ki", "tau", "jau", and "du", as well as a small set of related words, in that order. This tier is closed, meaning that it is very rare for new options to be added to it. The options are as follows, in this order:

(List 1:1)

  1. {"ce'u", "ce"}.
  2. {"ke'a", "ki"}.
  3. {"tu'a", "tau"}.
  4. {"joi", "jei"}.
  5. {"jo'u", "jau"}.
  6. {"jo'u", "joi"}.
  7. {"jo'u", "jei"}.
  8. {"du'u", "du"}.

(End of list.)

Note that this list follows what one might expect from the name of the dialect family, except for the fourth entry which is put there for technical reasons.

There are 8 entries in the list. Each entry gets assigned a bit, which is on or off depending on whether the utterer whishes to activate the swap; "on" and "off" are each assigned one of the symbols "0" or "1" bijectively based on mode specification (see earlier). The bits are arranged into a string in the order in which their corresponding options are presented in the immediately prior list so that the nth bit represents exactly the nth entry in the list and its value (represented by "0" xor "1") represents the activation status of that option. So, for example, if the mode is "1", then "00100001" means exactly that "tu'a" and "tau" are mutually swapped and that "du'u" and "du" are mutually swapped, in this tier. This string is the version specification precursor. As it is eight bits long, it can be converted to a two-digit hexadecimal string; for the sake of clarity, the last bit in the version specification precursor is in the singles ("2^0"'s) position while thebfirst bit therein is in the "2^7"'s position. This must be done. The resulting two-digit hexadecimal string is the final version specifier.

Thus, just for emphasis, there are 2^8 versions in this tier, each having its own two-digit hexadecimal version name.


If more entries are added to this list, this method must be revised. Additionally, it is is advised that they come either at the end or the beginning, for the sake of back-compatibility.

When multiple entries swap overlapping words, they are applied in left-to-right (standard) reading order in the bit string (od est: earlier/lesser-numbered options in the aforementioned list are applied first). So, for example, if both {"jo'u", "joi"} (option #6) and {"joi", "jei"} (option #4), which overlap at "joi", are "on", then the following occurs:

  • Initially, "joi" means CLL-"joi", "jei" means CLL-"jei", "jo'u" means CLL-"jo'u".
  • Then, option #4 is applied (despite my presentation of saying option #6 and then option #4). The result is that new-"joi" means CLL-"jei" and new-"jei" means CLL-"joi". "jo'u" is untouched and still means CLL-"jo'u".
  • Then, option #6 is applied. Consequently, newer-"joi" means CLL-"jo'u", and newer-"jo'u" means new-"joi" (which is CLL-"jei"). New-"jei" is untouched and still means CLL-"joi". This terminates the overlapping swaps.
  • In conclusion, the final state is that "joi" now means CLL-"jo'u", "jei" now means CLL-"joi", and "jo'u" now means CLL-"jei".


  • If none of these options are activated, then the version is "00" when the mode specification is "1"; the version is "FF" if the mode is "0". But why would one specify the mode and tier if one were not going to use it at all?
  • If all of the options are activated (hierarchically, remember), then the version is "FF" if the mode is "1"; the version is "00" if the mode is "0".
  • If options #1, #2, #3, and #8 are activated (but none of the rest (that is: words beginning with "j") are activated), then the version specification precursor in mode "1" is "11100001"; thus, in this mode, the version specification is "E1" ("rei pa"). In "0" mode, then the precursor is "00011110", so the version specification is "1E" ("pa rei"). Note that it is not always the case that the hexadeximal digits are swapped.


The version specification may be immediately preceded by ASCII "a" (Lojban: ".a'y bu"). This does not affect the process of converting a version specification precursor to the numeric part of the final version specification for any given string (for the version specification precursor); it is simply appended to the beginning of the version specification. Iff this is the case, then everything specified previous for Tier 1 applies, but the following ordered list is supposed instead:

(List 1:2)

  1. {"ce'u", "ce"}.
  2. {"ke'a", "ki"}.
  3. {"tu'a", "tau"}.
  4. {"du'u", "du"}.
  5. {"joi", "jei"}.
  6. {"jo'u", "jau"}.
  7. {"jo'u", "joi"}.
  8. {"jo'u", "jei"}.

(End of list.)

This is done for the sake of grouping all of the "j"-initial words, which have a lot of overlap together in one hexadecimal digit.

So, in Tier 1 for a given mode, version "5C" (from precursor: "01011100") is equivalent to version "a4#E" (from precursor: "01001110").

Tier 2: cmavo-swapping - secondary proposed swaps, miscellaneous in nature

Tier 3: cmavo-swapping - effecting NU

Tier 4: cmavo-swapping - scalars and UI modifiers

Tier 5: cmavo-swapping - effected by deep reforms of the connective system

Tier 6: cmavo-swapping - effecting PA

Tier 7: rafsi-swapping