jaidedctrl wrote on April 9, 2019 at 5:39 PM (edited on April 9, 2019 at 6:55 PM)

yes, this!

I've been thinking for a while that we should switch from plain-plaintext to a sort of meta-plaintext. it could store multiple values in the same position; different text would be shown in your text-editor depending on the language, and it'd be converted to plain-plaintext when editing finishes (or programs would support this multi-lang meta-plaintext, or it'd be handled by the kernel/FS drivers somehow).

EDIT:

I.E., person A sees "<body>", person B sees "<korpo>", but both values are stored in the file at the index 1234. Indexes should be used for phrases (AKA meanings)-- "if true then {add 1 2 3}" would be one index, let's say 3. There can be many different values per index (for multi-lang)-- there might be an esperanto index at 3, too, "se vera do {adici 1 2 3}". The particular index displayed would be determined by your language, or the one you specify.

Since there are multiple values for the same index, they'd all have "key" used to access it-- the french might be "fr", chinese "zh", etc. And since indexes are directly related to meaning, people would need to manually specify when a "block" ends and begins-- a simple keybinding in text-editors could ease that a lot. Some additional add-ons for visualizing the different blocks would make it easier to move blocks around in the file, etc.

There also ought to be a key designated as the default for each file-- "en" is safe, for compatibility levels.

If this is implemented on the system-library-side, core functions for opening files and reading data streams should accept an additional argument-- key. If the key isn't specified, then the default key is assumed, and the functions only pass along a data-stream (or what have you) with the file of default indexes. Thus compatibility with old programs that don't understand meta-plaintext etc is preserved. Or something like that.