@SSolie: The reason I have done the strings now is for an immediate set of test strings,
currently I am working on the InputHandler and trying to work up how to split it in half and only require the independant process to access any ".language" registered hooks for Input Modes.
Each "Language" will register as having 1 or more "modes" based on Glyph groupings (UTF-8 will be the default encoding for the Locale preferred languages listing).
Right now I am a little bit "into the darkness" with going past what I originally had in mind, however I am sticking with native libraries where possible.
a full set of complete UTF-8 strings can be found in the "Japanese.Language" and an incomplete set of "ISO-2022-JP" strings in the "Japanese_ISO-2022-JP.charset"
I have also managed to locate and confirm the "Native Language Name" for Korean and add that as well.
I'd estimate that I have maybe around 32-40% of the whole project completed but there is still a lot of work to do.
I have gone with a simple encoding for single glyph selections in UTF8 format currently and will be needing to execute additional calls into language libraries which register with perception.library.
I'm deliberately putting such calls as Hook methods to avoid messing with the official API call set.
But if anyone wants to try and use any of the existing hard-coded strings in the Japanese.Language module, they are fixed UTF-8 strings ready for testing.
I can also generate however many more as demand requires.