Hi all,

Considering:
- We need to avoid a scattered distributions of Meos differing only on interface language.
- Some world languages do need Unicode.
- We want to easily incorporate enhancements among the code, no matter the origin.
- We are asm programmers in an asm OS, so we don't need zero-terminated strings.
- It is nice to have the ability to switch between interface languages at runtime or to hot-plug another language in any moment.
- We need to easily provide regional variants for the world languages.
- To port MeOS to other languages, you just need to translate one file and with the help of a translator/wordprocessor.
- We need a coherent and useable system locale for internationalization managed and coordinated by menuetos.org.
- This will compact even more the OS and will give a coherent look and feel.

Given this, please feel free to comment or improve the following proposal:
To have a system-wide and centralized-managed collector of strings and localization info.
Each program to be completely transparent regarding interface localization.
Strings in table could be reagrupped for similarity or on other criteria.
System will manage string tables and all applications obtain access through a system call. (In the example provided, I considered an unexisting call: 19)

Haven't look at the code - but be sure to sort the sting keys (whether they are strings themselves, or DWORDs, or another thing), so you can use a binary search while looking up strings...

Really? AFAIK all world languages have at least one 8-bit codepage (and I think all they have at least two by M$ - OEM (DOS) and ANSI (Windows)).



Hmm... I like to use ASCIIZ strings in asm.

Such affirmation is not very polite, neonz. It simply shows that you don't know all world languages
Why do you think Unicode exists for?



Don't worry, you can continue to do it without problem. The proposal is not mutex. To handle constant strings with ASCIIZ is only a little unnecessary overhead.

AFAIK Unicode exists to get out of need to switch codepages (as it have all characters included). Believe or not, but there exists hundreths of 8-bit codepages around. And if there exists some language that does not have 8-bit codepage for it, it's possible that it isn't in Unicode too (because if such language users would need to use it in computers, they have been created 8-bit codepage by themselves).

So, you'd rather like an 8-bit representation with different codepages, that means a filename or string looks different in different countries? And you believe that all languages can do with 8-bit codepages?

I wonder why MicroSoft went to the trouble of making NT 100% unicode natively, and use unicode filenames in NTFS

If you use UNICODE UTF-8 you can use al character set of UNICODE but it's compatible with ASCII and then most MenuetOS programs don't need to rewrite if you use english. I think that is the best solution, think in BeOS and most new Requests For Comments (RFCs) like xml specifications that suport UTF-8.
Good look.

SamuelGaliza,
I think we can do it well with UTF-8, I'm going to try it.

I have only one doubt: I wonder, as f0dder says, why WinNT, but also KDE and Gnome go fully Unicode?

Note for neonz:
A mean alphabetized person in China would recognize arround 5.000 different symbols. A well educated chinese would recognize between 30.000 and 60.000 different symbols. A chinese linguist even more than double than that.

That means a total of 234 codepages.

http://www.unicode.org/

I think we don't need to add more stuff to MenuetOS,
if somebody wants their own language version they can have it,
as soon as you start adding UNIVERSAL stuff to MenuetOS that is rarely used by 90% of users you are on a fast track to a Windows..

I would say keep it simple.

You haven't downloaded it yet, I suppose?

I'm talking about simplification.

Look at the mess with the few different distributions with different features colliding to each other.

I'm using .77 3.0d
I just left the kernel compiled..

I wanted just to warn you guys, simplification - I'm all for it!

mhack,
If you want to do a sincere warn, please have the courtesy to give a detailed look at the matter, to avoid any preconcepts.

And if after you have given a detailed look you still think there is any overcomplication, please point it up in order to fix it.

The same is valid for all people posting in threads without taking the time to look at what the subject is related. This leads in many unnecessary rework and friends discouraged.

pelaillo,

I guess you right, please accept my apologies!

mhack

You are welcome.

The "Mess" of course is our playground.

If there were just ONE way then we would only have ONE flavor.

I like pistachio but not only pistachio.

The best WILL rise to the top.

Just a matter of time and co-operation.

Whining is pretty much a waste of time.

The CODE speaks for itself. No crowing or whining needed.

Let the various releases speak for themselves.

Pick it apart put it together your way.

Is this not supposed to be a learning experience?

Later.

Please look at the comment above: "...differing only on interface language"
I do appreciate the different implementations out there and I agree about the fact that only the CODE says the last word.

It is sad that none do talk about the very small CODE I provide here to show my approach, because otherwise you will see a different aspect.

To resume in a little paragraph:
Instead of having all constant strings scattered all inside the programs, we could have a uniform resource collector to be able to save space, maintain easy the translations and switch between languages hotplugging it at runtime if we prefer.

I am doing it. This was just a dream about team working and resource sharing. Don't worry, I just turn off the annoiance.

There is some code from unicode.org specs.
It´s to convert UTC-4 (UNICODE) to UTF-16 (UNICODE used by Java) and UTF-8 (UNICODE compatible with ASCII).
You can see it at http://www.unicode.org/Public/PROGRAMS/CVTUTF/

Hi Pelaillo,

When compiling the downloaded Locale package with FASM 1.51 in Menuet It will not get past about 2 inc files. The longfilenames~1 seem to be messing it up. Which ver of FASM did you use?

Could filenames be as:

local_es.inc

and

local_en.inc to comply w 8.3 ?




If I understand what you've written MEMUSE will have switchable languages from (es to en) when I get it compiled?

Thanks, Mark

[quote=boglite]Which ver of FASM did you use?[/quote]

FASM 1.52. I will give a look at what happens.

OK. fixed.

The idea is to be able to switch at runtime. Applications should not have strings hardcoded inside but instead ask kernel for string location. It is up to the kernel to decide which language is currently using.

Thanks.

heh, 8.3? Menuet doesn't support LFN?