Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Translate code to English #4

Closed
limyz opened this issue Mar 4, 2016 · 11 comments · Fixed by #40
Closed

Translate code to English #4

limyz opened this issue Mar 4, 2016 · 11 comments · Fixed by #40
Assignees

Comments

@limyz
Copy link
Owner

limyz commented Mar 4, 2016

No description provided.

@ericpignet
Copy link
Collaborator

I have big difficulties to read code in Japanese (forgot most of my Japanese lessons in uni, except katakana).
So when investigating issue #33 (and with the idea of doing some more changes in DTXMania in the future) I translated to English all filenames as well as many methods and variables widely used in the project.
This is far from being the whole project but it's a good start.

Would you accept a pull request with a huge lot of translations to English on master branch?
I fear this may cause problems for ongoing changes in this repo, and to import possible upstream fixes from original verK.
But on the other hand, it would make contributions from English speaking developers much easier.
What do you think?
If this is not an option, I will just commit my translation to a branch of my own fork, and maintain it on my own.

@limyz
Copy link
Owner Author

limyz commented Aug 11, 2020

This has been initially raised as a concern since 2016, feel free to raise a PR and we will do a merge immediately

@fisyher
Copy link
Collaborator

fisyher commented Aug 14, 2020

Yes, you are right that it may cause problems importing upstream fixes, it may also cause major merge conflicts with my other branch if the variables, class and function names are renamed directly. Perhaps another way is to add their translated names in a line comment above each of them?

@ericpignet
Copy link
Collaborator

It would be possible to add translations as comments above class/functions/variables but I'm not sure how much it would help readability, at least for people who can't speak Japanese at all. The body of all functions would still be in Japanese.
What I'm doing at the moment is I'm translating one symbol (class names, methods and public members only) and I'm using Visual Studio to propagate it everywhere. The good thing is that after translating the most used symbols, which are used everywhere, it helps readability of the functions which are not translated.
See what I have so far here:
https://github.com/ericpignet/DTXmaniaXG/tree/english/DTXManiaProject

My questions are:

  • how many fixes are you retrofitting from upstream?
  • Is VerK project (kairera?) still working on 3.x branch? Is 4.x branch close enough for changes to be imported easily?
    I guess it's a balance between how much changes we want to do on 3.62 and how much we want to retrofit. If the balance is on our side, it's worth translating.

For now I can keep my branch on the side. If you want you can create an 'english' branch on the limyz project and I would merge my 'english' branch to this one. It's really up to you.

@limyz
Copy link
Owner Author

limyz commented Aug 17, 2020

Attempts to contact @kairera0467 (https://twitter.com/kairera0467) over GitHub or Twitter is lacklustre at best. Upstream fixes will largely depend on commits made by kairera in the verk svn (See https://osdn.net/projects/dtxmaniaxg-verk/scm/git/dtxmaniaxg-verk-git).

The 4.x branch is severely bugged, probably due to a deviation from the SlimDX libraries (DirectX 9 is rather old) and is incompatible with the current branch. I doubt we will work on this branch in the foreseeable future.

We can also look at current forks of DTXMania as of date (e.g DTXMania2, DTXMania AL) Sadly, DTXAL has not disclosed its source code.

@ericpignet
Copy link
Collaborator

Understood.
There's also the original DTXMania which is still active, but I understand it's still lacking left pedal and other stuff added in XG.
That's good you at least tried to contact the verK developer. But from what you're saying it's not likely we will have many upstream fixes/changes to backport.

So what's the plan for English translation?
If you want, I can wait until @fisyher has merged his big SQLite config pull request, then try to merge my English pull request on top of it. There will probably be a lot of conflicts to manually solve, but I can try.
Again my focus is not to translate 100% code, but at least the class, methods and most public variables. Local variables can stay in Japanese for now.
What do you think?

@limyz
Copy link
Owner Author

limyz commented Aug 21, 2020

Our primary concerns are still upstream fixes from the svn and here's our options:

  • Split into 2 branches namely:
    • english (primary branch)
    • japanese (to continue to allow upstream fixes)
  • Stick to a single branch with English comments on top of all existing Japanese code (this is a better option as it allows quick merging of upstream fixes and since (not everything) only the classes, methods and public variables are translated.)

The latter option also allows easier merging of code from other forks. (reverse engineering DTXMania AL shows very similar file and folder structures).

@fisyher
Copy link
Collaborator

fisyher commented Aug 21, 2020

Understood.
There's also the original DTXMania which is still active, but I understand it's still lacking left pedal and other stuff added in XG.
That's good you at least tried to contact the verK developer. But from what you're saying it's not likely we will have many upstream fixes/changes to backport.

So what's the plan for English translation?
If you want, I can wait until @fisyher has merged his big SQLite config pull request, then try to merge my English pull request on top of it. There will probably be a lot of conflicts to manually solve, but I can try.
Again my focus is not to translate 100% code, but at least the class, methods and most public variables. Local variables can stay in Japanese for now.
What do you think?

The SQLite config branch is just a proof-of-concept branch to test if config.ini can be replaced with a config.sqlite file, which I don't plan to merge back anytime soon. I think we should wrap up the English translation branch first, then PR merge back before we continue any feature / enhancement work since the changes in the English branch are HUGE

On a side note, I used this to translate Japanese code and comments as recommended by @sakamoto-neko https://www.deepl.com/en/translator

@limyz Translated code with original Japanese names in comments work too. Can consider that as an option

@ericpignet
Copy link
Collaborator

Hi,
I'm fine with keeping Japanese names as comments in the future, but I'm not too much into going back to the hundreds of translated terms and add the comments.
I tried to do word for word translation whenever possible (with Google Translate via Visual Studio translator extension), to stay as close as possible from the original Japanese code.
So it's pretty easy to go back and forth between the same file in English and in Japanese.

So what do I do? Can I propose a pull request to your master branch (when I'm ready)? you can do a Japanese branch from the revision just before English translation if you want.

Also, just throwing ideas here, we mentioned in the Discord server creating an English language DTXMania wiki on Github. We could create a new Github Organisation (project managed by mutliple people) for DTXMania international community and host the English branch there as well as the wiki. @limyz could keep the release management but we would all have rights to manage branches and review/merge each other's pull request.

@fisyher
Copy link
Collaborator

fisyher commented Aug 24, 2020

Before proposing a pull request, please also update the DTXCreator solution with the changes you have made for FDK. It is currently not build-able.

@ericpignet
Copy link
Collaborator

Yes sure. What's on Github at the moment is some work in progress, a bit old. For DTXCreator I have integrated the changes done in FDK and translated the file names and classes, but I've not translated the classes/methods/file names.
For now I would like to have confirmation that you are all in favor of eventually merging on limyz/master, because if it's not the case I may do things differently.

@limyz limyz linked a pull request Aug 25, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants