Last update: December 31, 2009
The idea here is to have a version of the Kailye into natural language, for expressing peculiar Kailye contents, such as displaying rules when entering a place, or into covenants, contracts, etc. Such natural language content must display as normal human sentences, into the language and character set of the reader. It will also generally appear as an element of a longer text (rules, contract, group charter, etc.). This method allows to bind together an human element (a rule) and a computer element (a flag).
should translate into a well formed sentence such as:
"Nudity is not allowed."
A first difficulty here is that the common use is to tell what is forbidden, while the Kailye tells what is allowed. And in case a new category is added in a further version of Kailye, such as protected, it will illogically appear as forbidden.
A second difficulty is that the Kailye message is very accurate: in the example, silks are allowed, while there is no consensus as to what they qualify as clothed or nudity. This leads to a more complex sentence, for instance in french:
«La nudité n'est pas admise, mais les strings le sont»
A third difficulty is that the designer of a place, or writer of a contract, will not be able to check an automated translation in all the languages.
It appears difficult to automatically translate Kailye flags into natural language rules, with the today (2009) translators, without taking a serious risk of misinterpretation, in domains where such misinterpretations can easily lead to faux-pas, abuses or conflicts. Such a 100% reliable automated translation is unlikely to appear soon. Anyway standard translators will not understand the Kailye message itself, as it has a computer syntax instead of being straight English.
In more, such a translation will vary, depending on the translator, so that no Kailye system will be able to recover the Kailye meaning from an automatically translated text. And a manually translated version neither.
So we are bound to use a look-out translation table of ready made sentences. Happily the Kailye flags are not so numerous, so that we can use simple tables or database of ready-made sentences, one per language, somewhere on the net.
So the proposed solution is simply a <kailye version="x"></kailye> HTML or XML tag, indicating that the enclosed text is a Kailye message in the mnemonics syntax. For common Internet browsers, which do not understand this tag, it works as a <span> tag, and the Kailye message is displayed as the mnemonic syntax into the current text format, or in a CSS style if one is specified.
However, in some specialized text viewers, such as in the WEM browser, the window for displaying rules or covenants (which is an HTML viewer with a reduced set of HTML/CSS tags), the presence of a «translate» parameter will provoke the translation in the specified language, using the specified look-out table. The «translate» value is the normalized value of ISO639-3 (or ISO639-2, or ISO639-1 by order of preference). A value such as "user" will provoke the translation in the user's language.
<kailye version="x" translate="xxx" table="http://...">message</kailye>
Of course the URL is that of the translation table. But the kailye tag is not an hyperlink.
If there is some doubt on the natural language translation, it is better to display the Kailye text separately, as the legally binding reference:
The second line will provoke the display of the Kailye message into its computer syntax and Latin alphabet. (In this case, we must of course display the mnemonics format, not the code format). And anyway, if the look-out table is not found, or the flag is not understood, then the Kaylye mnemonics syntax is displayed instead: the message must never be invisible or ignored.
The worse issue is about forming sentences:
a simplistic word to word translation would be: «Allowed clothing: hidden, covered, common, light, bikini,silks»
But ideally we should get: «Nudity is not allowed, but silks are». So we should rather use a predefined sentence for each case:
~clothing,hidden,covered,common,light,bikini,silks,nude; Free clothing or nudity
~clothing,any; Free clothing or nudity
~clothing,common,light,bikini,silks; Nudity is not allowed, save silks
~clothing,common,light,bikini; Nudity is not allowed beyond bikinis
~clothing,covered,common,light; Nudity is not allowed beyond light clothes
~clothing,covered,common; No nudity or light clothing allowed
~clothing,light,bikini,silks,nude; Nudity and light clothing allowed
~clothing,bikini,silks,nude; Nudity and bikini allowed (One understand that silks are)
~clothing,silks,nude; Nudity or silks are mandatory
~clothing,nude; Nudity is mandatory
Hierarchical names or list with no predefined translations are word to word translated.
In the example of clothing, hidden and covered should not be in default lists for all uses, but they must be present only in the special cases where they are requested.
At last, we can display directly a natural language Kailye message, created with a look-out translation table, that general HTML or XML text editors or viewers will be able to display correctly:
<kailye version="x" language="xxx" table="http://...">message</kailye>
In this case, the message is already translated. Non-HTML tags are ignored or considered as <span>. But a Kailye system is still able to identify and recover the Kailye message from the natural language, using the lookout table in the reverse way.
It is to be noted that, as explained in the next section Intellectual property statute of the Kailye language, the word «kailye» is protected by the general GNU GPL license of the Kailye language. So it is a reserved HTML or XML tag, to be used only for marking Kailye content. Browser implementations must also follow the rules described above.
-This version zero of the Kailye language is covered by a GNU GPL license, didtinct of the WEM licence. The only author is Richard Trigaux (Yichard Muni in Second Life).
-The «Kailye» name is covered by the same terms. The Kailye is a computer language name, just as python, C, Java, etc.
-All future versions, modifications, additions, MUST be covered by the same terms, whoever their author.
-Other future authors or contributors, persons or companies, are free to acknowledge their contribution.
-Any of these texts can be reproduced without asking authorisation, provided that the source, license type and authorship are indicated.
-Anybody is free to implement and use the Kailye language for any legal purpose save military, for free or for commercial use, without having to ask for authorisation or without owing any money.
-The previous point is valid TO THE CONDITION that the resulting product or creation is interoperable with similar or related products or software of other source or brand. Use of Kailye elements is not free into closed systems, such as for instance a simulator or a platform world with can be accessed with only some specialized browser or special identity. In this case the Kailye Intellectual property rights are those of a classical copyright owned by Richard Trigaux (expandable to other contributors).
Proof of anteriority:
Legal disclaimers (laws of democratic countries, or International Law if none apply):
-Use of the Kmetaconn command or the Konnect command is allowed only into the context of the WEM architecture, or another with the same legal bindings, into the legal conditions described in 11.4 - Judiciary uses of the Konnect command and 11.5 - World metaconnexion request: the Kmetaconn command.
-Use of Kailye flags about personal data is allowed only if they reflect exact facts and are used into the legal conditions about privacy protection. This data is considered private, as long as the concerned person does not specify otherwise.
-Places or elements with the private flag are legally private.
-Use of ~legal Kailye covenants and other legally binding elements is allowed only if they are used into the legal conditions about such bindings. But if so, they actually legally bind the concerned persons or companies, under their responsibility.
-Use, abuse or default of legal WEM and Kailye elements is under the responsibility of the involved persons or companies.