Jump to content

Mangos translation


Recommended Posts

Posted

I don't really understand which textes you suggest to actually translate - error/ debug output log shouldn't be translated in my view, because everyone needs to easily understand it, and output to client is handled by DB-localization already

Posted

Is the support for Windows bad? Does anyone know a better system for the translation of the c++ strings?

For example:

 sLog.outError("Cannot connect to database");

or

sLog.outError("Processors marked in UseProcessors bitmask (hex) %x not accessible for mangosd. Accessible processors bitmask (hex): %x",Aff,appAff);

Posted

mangos have builting way add localization for texts. Maybe not so good automated as some existed tools but

from other side that can be used for case: mangos_string table. Most texts send to client already support localizations.

Internal error reporting to console logs mostly not localized just because devs and expected most admins know english in some acceptable level for understand this error messages.

Posted

It depends. It might not be a bad idea to streamline to localization used for console output, or e.g. error messages. It's at least worth a try.

It may be helpful for people if they can read output in their native language.

As mentioned above, currently there are multiple methods used in MaNGOS used to localize both the system, and the content. If that can be improved by using a localization system like gettext, I'd say take a shot.

Posted

Possible, we have 2 diff cases:

1) client side send texts, including stored in DB. It's dependent from client locale (that can be != server locale).

And gettext low chance can be used in this case. mangos_strings + localization shadow table in DB is good existed sollution.

2) server side only texts (console/etc). Adding tis all to mangos_strings can be too havy task, maybe in this case better use as in other similar cases gettext way or alt. tool if it portable work for suported by mangos platforms, specially win/some wide linux/some wide unixs

Posted

Use case 2) is where gettext may help, to make things more user friendly. But that is really only worth if gettext now has better platform support. Windows always had a hell of a dependency chain involved here. If that has improved, gettext may be worth pursuing.

Use case 1) is where gettext and most other localization systems fail anyway, thus it's ruled out for sure.

Posted

i vote against translating any console output. console output (of any program, not just mangos) should *always* be in english, so that you can just copy&paste it and everybody will understand it. if you run into a problem and post your log here, we can understand it. if you have a translated version, we won't.

the best example is visual studio: it always has translated versions, so if someone posts his VS-error-logs here, we don't understand them. but VS does it good too: they have error-codes. so you just have to search for those error-codes on MSDN and you'll find the english version of the error. it just takes more time.

Posted
i vote against translating any console output. console output (of any program, not just mangos) should *always* be in english, so that you can just copy&paste it and everybody will understand it. if you run into a problem and post your log here, we can understand it. if you have a translated version, we won't.

quote, it's better to spend time working to mangos instead to waste time on translating it. I don't know why we should need to translate it.

My english wasn't very good when I started to use mangos (and it's still not perfect^^), but I improved it a bit using mangos (follow forums, read tutorials, etc...) also google translator helps a lot in learning new terms

Posted

Lots of really good points on both sides of this argument, only thing i can say that other software will do on error is return a numeric error id

for example

mysql> SELECT * FROM no_such_table

ERROR 1146 (42S02): Table 'test.no_such_table' doesn't exist

I think numeric error codes would be useful, as long as anyone who posted an error included the error code the language wouldn't matter since 1146 in English still means 1146 in French (a wiki page could have the appropriate translations of the error description)

but like DasBlub stated if multiple translations are running around it will be harder to "link" the errors to other forum threads, even if you translate a non-English error to English using google translate it won't be 100% the same as the original in most cases

Posted
Lots of really good points on both sides of this argument, only thing i can say that other software will do on error is return a numeric error id

for example

mysql> SELECT * FROM no_such_table

ERROR 1146 (42S02): Table 'test.no_such_table' doesn't exist

I think numeric error codes would be useful, as long as anyone who posted an error included the error code the language wouldn't matter since 1146 in English still means 1146 in French (a wiki page could have the appropriate translations of the error description)

but like DasBlub stated if multiple translations are running around it will be harder to "link" the errors to other forum threads, even if you translate a non-English error to English using google translate it won't be 100% the same as the original in most cases

Okay. That´s also a interesting idea. But I see, that a translation isn`t very useful this moment. It's more work, for the implementation of the translation system and the support people, than it helps.

Posted

When mangos is finished with all content, then its time to translate (and that will never happen)

Guys really, it should be english output, but maby you could add errorcodes so the russians/germans can read (let them have the annoying part to search after error codes) in my opinion there shall only be one language on earth, and its english ;D (im from sweden lul)

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use