[MPEG-OTSPEC] Many to many substitution and localization

[John Hudson]

a) everything you have described involves characters, not glyphs.

b) machine translation already works at the receiving end, and is able 
to handle arbitrary text (and speech) rather than being limited to a set 
of string localisations.

JH


On 2024-10-01 12:41, William_J_G Overington via mpeg-otspec wrote:
>
> John Hudson replied.
>
>
> Thank you for replying.
>
>
> John Hudson wrote as follows.
>
>
> > You are proposing breaking something that already works in order to 
> make it work in a more convoluted and less useful way.
>
>
> I am not proposing breaking anything, I am suggesting an additional 
> facility.
>
>
> I do not purport to know much about localization. So maybe I have got 
> it wrong.
>
>
> So I will try to explain my thinking and readers can decide whether 
> this is a new idea, and if so, what they opine about it and about my 
> suggested new layout feature becoming added to the font standard.
>
>
> Around 2009 there was lots of discussion about whether to encode emoji 
> each as a character in ISO/IEC 10646.
>
>
> I wondered what else could be encoded as a character.
>
>
> Letters, digits, punctuation, spaces, symbols - some of each of those 
> had been encoded.
>
>
> "What about whole sentences?" I thought.
>
>
> So I did a thought experiment.
>
>
> Consider a sentence such as "It is snowing.".
>
>
> Suppose that that sentence is encoded as a character.
>
>
> So someone who wants to send the message "It is snowing." can look up 
> the character, maybe from a printed list, or in a menu in an email 
> program, and send it in an email to a friend.
>
>
> The friend can then find the meaning of the character, or a computer 
> system can decode it automatically, and the message "It is snowing." 
> becomes known to the friend.
>
>
> Yes, it could be done, but it is not of any use.
>
>
> I then realized that the decoding by or for the friend need not be 
> into the same language, so the received message could have gone 
> ("tunneled") through the language barrier.
>
>
> Oh!
>
>
> So the encoded character was a localizable sentence.
>
>
> Not localized. But localizable.
>
>
> So the significance of what I am suggesting is that the localization 
> is at the receiving end of a communication, not at the sending end.
>
>
> So in the scenario that is in the slide show, the link repeated here 
> for convenience,
>
>
> http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf 
> <http://www.users.globalnet.co.uk/~ngo/slide_show_about_localizable_sentences.pdf>
>
>
> Albert does not need to know the language in which Sonja works.
>
>
> Extending the simulation, Sonja can be sending out localizable emails 
> to various people in various countries and upon receipt each email is 
> localized into the language being used by the person at that location.
>
>
> So this suggestion is based on my opinion that that would be good to 
> be able to do. I do not know if it can already be done.
>
>
> The only system of which I am aware that uses code numbers that can be 
> used to send precise information through the language barrier is 
> SNOMED CT a clinical terminology system, though the code numbers are 
> not only for that purpose, they are used for accurate recording of 
> clinical records within a country.
>
>
> William Overington
>
>
> Tuesday 1 October 2024
>
>
> _______________________________________________
> mpeg-otspec mailing list
> mpeg-otspec at lists.aau.at
> https://lists.aau.at/mailman/listinfo/mpeg-otspec

-- 

John Hudson
Tiro Typeworks Ltdwww.tiro.com

Tiro Typeworks is physically located on islands
in the Salish Sea, on the traditional territory
of the Snuneymuxw and Penelakut First Nations.

__________

EMAIL HOUR
In the interests of productivity, I am only dealing
with email towards the end of the day, typically
between 4PM and 5PM. If you need to contact me more
urgently, please use other means.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20241003/c1ab47d8/attachment.htm>