You are not logged in.
Reasons for not nuking them:
- They make DeSmuME multilingual.
Reasons for nuking them:
- They're a pain to manage.
- They will be more of a pain to manage when we support 23 languages or so.
I am in favor of nuking them.
Post your opinion in this thread.
Later on, we will see the results of the poll and take an action.
Last edited by Luigi__ (2009-12-10 17:30:46)
Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.
Offline
I feel that you should poll the users if they are comfortable using the emu in english only.
If there is not enough support for other languages then it would be a waste of resources for developer to change the codes to cater to a very small minority (if it is a huge effort).
Another option is to have the important options translated in a multi-lingual file (faq or readme etc) if the minority needs help understanding the controls in english if you want to maintain in english only.
Just my thought.
Offline
For me, the translations are about the same kind of thing as render filters. They don't help the emulation, and I personally rarely use them, but some people want them. I have no idea how many people that is. One thing to consider is that, if we don't include translations in DeSmuME, then somebody is going to create and provide translations anyway, and thus the number of people who are using unofficial builds of DeSmuME and expecting it to work as well as the official builds will increase, which seems like a bad thing, but again, I'm not sure how many people we're actually talking about here.
Maybe there is some middle ground, like immediately nuking all translations after each release but re-adding them before the next release if we get an updated patch for a language for the new release or (like with English) if somebody is willing and able to actively maintain it. If nobody is and nobody provides a new one then I guess we could just leave the ignored language out of the next release in that case, but some languages would still be present if we got up-to-date patches for them, and we wouldn't have to be maintaining them until then before the release. (Maybe that's a bad idea for some reason?)
If we do keep the translations, it might help make things a little easier to maintain if we split each translation out to a separate file and include them from the main resources.rc. http://msdn.microsoft.com/en-us/library … g_multiple
Offline
Keep in mind we operate under the requirement of the .rc working in any visual studio version and .rc compatibility between visual studio versions is dodgy and any time you start to mess with that you may enter hell.
Offline
There are 45 dialogs in DeSmuME. With 5 versions each (French, English, Chinese simplified, Italian and Japanese), there are 225(!) dialog templates in total. What a hell.
If we had, say, 16 translations, that would be 720 dialog templates.
I don't use translations either. Language option permanently set to English for me.
If people want to make unofficial builds with translations, then it's their problem. If people want to use unofficial builds, it's their problem. We don't support unofficial builds, period.
Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.
Offline
ACTION PLANNED:
We won't nuke the translations right now.
However, any translation that is outdated and stays so before the release will be nuked.
Hoping everyone agrees with it.
Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.
Offline
ACTION PLANNED:
We won't nuke the translations right now.
However, any translation that is outdated and stays so before the release will be nuked.Hoping everyone agrees with it.
Well it makes perfectly sense to me that *any* translation that does *not* have an active translator to update the translation on each release, will get nuked. And that the ones that do get actively updated by 'someone' on each release stay in. Does that make sense to anyone else ?
Offline
It doesn't make sense to me. Who is going to round up all the active translators how long before each release? What a hassle.
Offline
ACTION PLANNED:
We won't nuke the translations right now.
However, any translation that is outdated and stays so before the release will be nuked.Hoping everyone agrees with it.
I think it is a good idea. I will do the chinese translation since it has been so outdated and you can include me as one of the active translator unless someone else want to do the chinese translation. Also, I am in the process of translating the FAQ menu layout option (if you want it when I finish).
Last edited by Pokefan999 (2009-12-23 03:02:23)
Offline
It doesn't make sense to me. Who is going to round up all the active translators how long before each release? What a hassle.
Welll, maybe then we need to define 'active translator' as someone who does the translation during the development cycle, while the code is being worked on, so it will be (nearly) finished when a release is upcoming ? 'active' = 'someone-that-doesnt-need-to-be-rounded-up' ? If a translation maintainer needs to be 'rounded up', then drop that translation ? Does that make more sense ?
Oh well, whatever, nevermind ..
Last edited by lbalbalba (2009-12-24 19:24:15)
Offline
zeromus wrote:It doesn't make sense to me. Who is going to round up all the active translators how long before each release? What a hassle.
Welll, maybe then we need to define 'active translator' as someone who does the translation during the development cycle, while the code is being worked on, so it will be (nearly) finished when a release is upcoming ? 'active' = 'someone-that-doesnt-need-to-be-rounded-up' ? If a translation maintainer needs to be 'rounded up', then drop that translation ? Does that make more sense ?
The active translator just need to inform the team what language he is translating / updating and it is an ongoing process to check, verify and update new changes.
If you have a comm channel to gather input from / inform all other developers before a public release, just include the active translators.
If the developer adds / updates a new menu option or dialogue template, I think all languages should be updated with the english template.
Otherwise keep a text file like the Changelog to include "rxxxx", "(which menu option is added / changed)" if other languages are not updated.
Either way, it helps the translator to keep track of changes and make the necessary update.
If languages are supported, then I would suggest that there is no hardcoding of "menu displayed text" in the codes (where possible) and Unicode friendly (if possible).
Just my thought.
Offline
Developers are not going to edit resources in every language whenever they change something. That is the whole point of this discussion. I don't want to worry about that junk, and the translator needs to whack everything and start over if he is uncertain whether his dialogs and menus are up to date.
Offline
Developers are not going to edit resources in every language whenever they change something. That is the whole point of this discussion. I don't want to worry about that junk, and the translator needs to whack everything and start over if he is uncertain whether his dialogs and menus are up to date.
I know the developer has the rights. It depends on whether you consider the active translators as part of the team or they are doing these stuff outside the scope of Desmume team needs.
I am fully aware of your stand as far as other languages are concern.
I am merely suggesting ways to help each other out as part of the team effort (no need to fire all your "cannons" when foreign languages are mentioned).
Just my personal thought.
Offline
Developers are not going to edit resources in every language whenever they change something. That is the whole point of this discussion. I don't want to worry about that junk, and the translator needs to whack everything and start over if he is uncertain whether his dialogs and menus are up to date.
Allright, gonna suggest something wildly insane here... but... would it theoretically be possible/feasible to introduce the concept of separate 'language files' (sorry, not a dev here), that could get updated and distributed separately from the desmume executable ? Which would allow the desmume devs to do a release whenever they feel like it, without having to care about the translations, and all the involved translation maintainers could then supply the translation files to be dropped in some ../translations/ dir to be picked up by the desmume executable ?
Have I gone insane here ?
Offline
Whatever made you think this topic was about what is theoretically possible or feasible? It has always been about what is convenient. It is not convenient to go one centimeter out of the way in order to facilitate translations.
Offline
It is not convenient to go one centimeter out of the way in order to facilitate translations.
Well then screw the translations.
Offline
Whatever made you think this topic was about what is theoretically possible or feasible? It has always been about what is convenient. It is not convenient to go one centimeter out of the way in order to facilitate translations.
It is fine if the developers won't "budge" one centimeter for translations but I would like to know the yardstick being used to determine if the translation is "outdated" and need to be "removed".
How up-to-date is considered updated enough to remain in the release?
Since translators are not getting any help from the developers, are the developers going to scrutinize the "foreign" emu layout (probably gibberish to you) and judge its value to the "foreign" users?
Will the developers get mutual agreement from translators before "removing a so-called outdated" translation?
Thinking aloud.
Last edited by Pokefan999 (2009-12-28 00:57:25)
Offline
It is fine if the developers won't "budge" one centimeter for translations but I would like to know the yardstick being used to determine if the translation is "outdated" and need to be "removed".
How up-to-date is considered updated enough to remain in the release?
Since translators are not getting any help from the developers, are the developers going to scrutinize the "foreign" emu layout (probably gibberish to you) and judge its value to the "foreign" users?
Will the developers get mutual agreement from translators before "removing a so-called outdated" translation?Thinking aloud.
Just 'thinking aloud' as well: Just nuke *all* translations and it becomes a non-issue since you dont have to find a way to determine if its 'outdated', *plus* it fulfills the requirement of developers not having to to go one centimeter out of the way in order to facilitate translations.
Offline
ACTION PLANNED:
We won't nuke the translations right now.
However, any translation that is outdated and stays so before the release will be nuked.Hoping everyone agrees with it.
Just 'thinking aloud' as well: Just nuke *all* translations and it becomes a non-issue since you dont have to find a way to determine if its 'outdated', *plus* it fulfills the requirement of developers not having to to go one centimeter out of the way in order to facilitate translations.
Based on the "ACTION PLANNED" listed above, the developer driving this task is seeking agreement on "nuking outdated translation" before a public release.
As such, the yardstick for determining "outdated translation" need to be found and agreed upon.
To complete the action plan, we need to ask further questions, e.g. as stated in my earlier comment.
How up-to-date is considered updated enough to remain in the release?
Since translators are not getting any help from the developers, are the developers going to scrutinize the "foreign" emu layout (probably gibberish to you) and judge its value to the "foreign" users?
Will the developers get mutual agreement from translators before "removing a so-called outdated" translation?
Whether "developers are willing to budge one centimeter or not is about their rights and preference" on the translation matter which we can ask and they can reject.
I put forth an earlier suggestion in view of the better needs of active translation and I will let others judge the value of your comments("nuke *all* translations") in such a discussion topic.
Offline
oh lord i just love the drama. personally I think this is all stupid and the status quo is fine.
but since someone wants to formalize, how about this:
when we get close to a release, we will post a thread in this forum which will be called "submit your #*@(#ing translations NOW for 0.9.6".
we wont post that thread until the .rc is stable and we are truly close to a release.
if anyone can't be arsed to read this forum or watch IRC then they can't be coordinated with and their translations are probably going to end up getting purged for too-much-out-of-dateness. we'll also make note of it in the svn checkin logs since that may be all some people read.
this is only going 5 millimeters out of the way, so it falls under the threshold of inconvenience, although dealing with all the language patches nearly all at once is about 9.8 mm of inconvenience.
but i'll let luigi do the purging though since he opened this can of worms and I like leaving old and crappy translations checked in, since it is my passive aggressive way of punishing gobbledegook speakers.
Offline
Hmm, who are the nonsensical speakers???
Since you have set the rules and formalize the "Action Planned", we will have to abide by it.
Last edited by Pokefan999 (2009-12-29 07:11:30)
Offline
Translation is a waste of time. Pretty much everyone on the internet knows English to an extent. If they don't understand something they can always use Google Translate. English is my third language and I always set the language to English.
Offline
Agreed.
Not to mention there are certain things which are English only and can only be made multilingual with extra perfectionism.
Kuribo64 - If you're wondering where Mario__ is, he's currently saving Peach__ once again.
Offline