send me/attach the 50% to translateAlright, thanks for the help, Savage!
Important information: this site is currently scheduled to go offline indefinitely by end of the year.
Help out with new language support in MexCom
-
- VIP member
- Posts: 185
- Joined: Mon Aug 28, 2006 2:07 pm
- Has thanked: 1 time
- Been thanked: 14 times
- Contact:
Here's what I have noticed "on the fly":Mr.Mouse wrote:Please do note down those lines that are not in the text file, but still need to be translated. I can have missed some, so you're right to point them out.
- Splash screen: status messages during startup (that's probably intentional ...?)
- Status bar: "AutoPreview = Off"
- Status bar, during load of editable game list: "Analysing BMS scripts..."
- "Open archive" dialogue, "MexScript source" group box: "Wiki (unofficial)"
- "Open archive" dialogue, "Filter" group box: "All", "Ext"
- "Open archive" dialogue, bottom right: "Type"
- "Tools" menu: "Scan file..."
- "Help" menu: "Help"
- Main window, context menu: "View <filename>"
- Main window, context menu: "Extract <filename>"
- Search box for multiple selection: basically all tooltips
- all of Jaeder Naub
No, you're right, that's useful. Now I have seen where this line belongs.Mr.Mouse wrote:Line 45: It has brackets around because it will be put in the textbox where people can enter a new folder name, so they'd notice that it is there that they should put the new text. But I guess its allright to remove them.
I thought so. However, more often than not the program seems to add additional blanks on its own, so I removed some of them from the translation to make it look right.Mr.Mouse wrote:Lines that end with blanks : this was intentional as they represent snippets of a whole sentence and some value in the program will be inserted in the sentence, like "MexCom supports "<insert number> " archive formats".
Shouldn't be a problem to fix the translation file if this changes in later versions.
The download page is not a problem. The translation of the manual, however, is indeed a hefty task.Mr.Mouse wrote:The next step would be to have also the MexCom download site translated, and how about the manual? LOL That would take considerable time!
Concering the current translation status: I have updated the attachment to my last post. I have fixed bugs as far as I could see them. For the rest, someone with a registered version will have to tell me which lines still need tweaking (especially regarding the length). A person speaking German would be great -- I don't know if all of my translations actually make sense in the program's context.
[Edit: Attached translated download page.]
You do not have the required permissions to view the files attached to this post.
-
- VIP member
- Posts: 185
- Joined: Mon Aug 28, 2006 2:07 pm
- Has thanked: 1 time
- Been thanked: 14 times
- Contact:
Great!Mr.Mouse wrote:Check it ! http://multiex.xentax.com/index_de.html
If you change the alternate text for the German flag from "Nederlandse taal" to "Deutsche Sprache", it'll be perfect.
Thanks to Mr.Mouse's generosity, I was now able to do the remaining checks myself ... so the attachment to the above post has once again been updated with what could be considered a final version. However, everybody is invited to find bugs I might have missed ...
Some additional observations regarding untranslated lines:
- MultiEx Editor: Status messages during Add/Delete
- MultiEx Editor: "Directory based batch job" dialogue title
- general: error messages (download error, mrf add failure etc.)
Additionally, the monospaced font used in some smaller labels doesn't seem to use the standard ANSI charset, which causes incorrect display of "special" characters. But that's just a minor thing ...
-
- Site Admin
- Posts: 4073
- Joined: Wed Jan 15, 2003 6:45 pm
- Location: Dungeons of Doom
- Has thanked: 450 times
- Been thanked: 682 times
- Contact:
Could you point out a few? So I can see if that can be fixed in-code for a future release.Deniz Oezmen wrote: Additionally, the monospaced font used in some smaller labels doesn't seem to use the standard ANSI charset, which causes incorrect display of "special" characters. But that's just a minor thing ...
-
- VIP member
- Posts: 185
- Joined: Mon Aug 28, 2006 2:07 pm
- Has thanked: 1 time
- Been thanked: 14 times
- Contact:
Two examples:
- MultiEx Editor: the info labels that function as "mouse hover" triggers or display the file/ressource size
- MRF manager: the captions of the columns in the left list box
These are the cases I noticed. If you try to have them display, say, an "ü", you will get a "³" instead. At least that happened on my system.
But perhaps not the application, but my fonts are the cause for this problem? Is the MRF manager list box on the left supposed to have a font different from the one on the right?
- MultiEx Editor: the info labels that function as "mouse hover" triggers or display the file/ressource size
- MRF manager: the captions of the columns in the left list box
These are the cases I noticed. If you try to have them display, say, an "ü", you will get a "³" instead. At least that happened on my system.
But perhaps not the application, but my fonts are the cause for this problem? Is the MRF manager list box on the left supposed to have a font different from the one on the right?
- Dinoguy1000
- Site Admin
- Posts: 786
- Joined: Mon Sep 13, 2004 1:55 am
- Has thanked: 154 times
- Been thanked: 163 times
- Dinoguy1000
- Site Admin
- Posts: 786
- Joined: Mon Sep 13, 2004 1:55 am
- Has thanked: 154 times
- Been thanked: 163 times
- alera
- advanced
- Posts: 71
- Joined: Fri Oct 06, 2006 2:33 am
- Has thanked: 14 times
- Been thanked: 5 times
Just to let your know that althrough japanese is part of the unicodelionheartuk wrote:Il give it a go with JAPANESE text.
It shouldnt be hard ot do.
BUT i dont know IF MEXCOM will even read it, as its UNICODE and not normal text.
If you KNOW its not gonna work then say and i wont do it lol.
THo id like soem help with JAPANESE as I am a busy man lately lol.
standard, japanese is also one of the many ansi codepages so it will be
posible to have MultiEx display japanese as long as the users
computer is configured with the right ansi codepage
eg: テスト <-- japanese :P Codepage 932 - Shift jis
That is ofcourse if the program passes the text strings as-is to windows
with for eg Set??TextA(A for Ansi) winapi. I don't know if you can go
wrong there thought
Mexcom was created with VB5, all strings are in UTF-16 format and converted when needed to ansi if calling AAPI. Code pages are the devil, asian scripts are still in multibyte format and its a big pain to program that in UTF16 is the way to go. But weither or not Mexcom will read it is another story, i'm not sure of the format of whatever hes using to read the languages in (resource/file/etc)
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
- lionheartuk
- double-veteran
- Posts: 749
- Joined: Tue May 16, 2006 10:55 pm
- Location: Everywhere
- Has thanked: 34 times
- Been thanked: 42 times
By HE you mean ME right?Rahly wrote:i'm not sure of the format of whatever hes using to read the languages in (resource/file/etc)
I actually have NO IDEA what unicode Japanese is lol, I just set the text documents to UTF8 when i save them.
As for WEBPAGES, well I have it set to UNICODE UTF8 all the time, BUT on the other hand i DO have the language bar and Japanese language support for all programs on my PC.
But to make CERTAIN JAPANESE ONLY programs work i do have to chane EVERYTHING to japanese, so they arnt just ANOYING squares that i cant read.
But yes as soon as MULTI EX supports UTF8 please feel free to contact me and I will translate the PROGRAM text into Japanese, though the MANUAL will take more PROFESIONAL japanese and seing as my sentance structure isnt all that good for LONG Sentances I will most likely need some help with that, though my japanese does get better on a DAILY basis.
Was THINKING of writing a translation program in VB6 to trnaslate english words into their ROMANJI counterparts, But i havent started it yet lol.
ムルãƒ
No, HE, that I was refering to is, Mr. Mouse. UTF-8 is a Unicode encoding. Since no OS i know of actually uses UTF-8 directly, and I highly doubt Mr.Mouse is doing any UTF-8<->UTF-16 transformation, it all depends on how hes reading the language data. Windows and *nix machines that have unicode support, all use UTF-16 encodings when talking on an OS level. If he has straight UTF-16 support, then you can do it. Programs like Notepad and Wordpad for windows support these formats.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)