Brazilian Portuguese (pt_BR) translation
MestreLion
I've been playing with Endgame: Singularity source code for a few
days, now I'm familiar enough to start contributing.
Questions:
- Are you accepting patches? What is your favorite workflow for
submissions? (zip files, patch files, cloned git repo, etc)
- Is development really stalled? I've noticed there are several bugs
in Google Code's tracking, some of them I was already able to fix
- My main goal in contributing is to improve translations. Currently,
a LOT of the interface is still hardcoded. Buttons, menu options,
mains screen, etc could have more translatable strings. And I'm
willing to do that, if you guys say its OK
- I have NO plans to change any of game's logic, mechanics or balance,
so do not fear: all my patches will be bug fixes / interface
improvements, NOT enhancements or new features/techs/locations/etc
Meanwhile, I've already done the Brazilian Portuguese (pt_BR)
translation, and I would be honored to see it merging with official
game. How can I send the data/*_pt_BR.dat files to you?
Thanks,
Rodrigo
Phil Bordelon
> Hi there Phil and all other developers!
>
> I've been playing with Endgame: Singularity source code for a few
> days, now I'm familiar enough to start contributing.
>
> Questions:
>
> - Are you accepting patches? What is your favorite workflow for
> submissions? (zip files, patch files, cloned git repo, etc)
>
> - Is development really stalled? I've noticed there are several bugs
> in Google Code's tracking, some of them I was already able to fix
These two go together: Yes, development is really stalled. That said,
one of the motivations of my switching the repository over to Git is
that it means people other than myself and EMH can have work-in-progress
repositories and, hopefully, lower the barrier to entry.
That said, if you've already done work despite my discouraging people
from doing so until there's a live fork, I'm not opposed to merging
it :) Either patches or a cloned repository are fine.
> - My main goal in contributing is to improve translations. Currently,
> a LOT of the interface is still hardcoded. Buttons, menu options,
> mains screen, etc could have more translatable strings. And I'm
> willing to do that, if you guys say its OK
In the back of my mind I've been mulling a complete rewrite of the
game from scratch, and one of the things said rewrite would fix is
this. That said, I don't know if I'm ever gonna get around to doing
that. And, yes, everything /should/ be translatable, even if it
currently isn't.
> - I have NO plans to change any of game's logic, mechanics or balance,
> so do not fear: all my patches will be bug fixes / interface
> improvements, NOT enhancements or new features/techs/locations/etc
>
> Meanwhile, I've already done the Brazilian Portuguese (pt_BR)
> translation, and I would be honored to see it merging with official
> game. How can I send the data/*_pt_BR.dat files to you?
As mentioned above, either patches or a cloned repository are fine.
Make sure to include a Changelog entry (in the proper style) if you
provide a cloned repository or git-style patches; if it's non-git
patches, I can add one myself before I do the commit.
P
MestreLion
http://code.google.com/r/rodrigoespiritosantosilva-endgamesingularity/
The branching convention is:
- Each feature/bugfix has it's own, separate branch
- Most branches have a corresponding Issue ID (at least in commit message)
- All branches are based on upstream (yours) master branch, so they can be merged/cherrypicked individually and indenpendetly. There are no inter-dependencies
- After a given branch is complete and/or stable, it is rebased/cherry-picked to my master branch.
So feel free to merge an individual branch, or import master and see the end result of my all work
There are several issues solved already:
- Tech tree reseting if language is changed mid-game
- Events not being translated if language is changed
- Saved games list was not sorted
Some on the way:
- -s|--singledir command line option is ignored
And some additions too:
- use of XDG dirs for saves and music
- small code refactoring (global vars and functions calls in g.py are an unholy mess)
- a neat .gitignore that excludes .pyc , music files and dotfiles
And, of course, my grand goal of making E:S fully translatable
Feel free to comment each of the features/bugfixes I've did. Any reply about them is welcome!
Last but not least... do you still use Google Code's Issue tracking system? I think it's a good place to discuss each item individually, sugestions, rationale for accepting or not, etc; Is there anyone keeping an eye there? I could add a new issue for each branch/feature/bugfix if you want
Best regards,
Rodrigo
Phil Bordelon
one part:
On 03/06/2012 08:05 AM, MestreLion wrote:
> Last but not least... do you still use Google Code's Issue tracking system?
> I think it's a good place to discuss each item individually, sugestions,
> rationale for accepting or not, etc; Is there anyone keeping an eye there? I
> could add a new issue for each branch/feature/bugfix if you want
I looked at it for the first time in probably a year the other weekend. I
doubt anyone else is. I wouldn't worry; I can go through your changes via
git.
P
MestreLion
It's been almost a week since I heard news from you. In the meantime I did many updates to my git clone. A brief summary of most important changes is:
- Official URL is now http://code.google.com/r/rodrigosilva-singularity/
- Branch ready to be merged to official repo is main (not master, which was not touched)
- All commits in main are independent from each other, so they may be cherry-picked in any order to your master
- Still, I strongly suggest that the 1st commit, the one that adds .gitignore and .gitattributes, is merged before the others, since it will provide a clean merge for Changelog edits and prevent unwanted files from being added.
Each commit in main represents the result of one feature branch. They are, in short:
- fix bug of techs being reset if language is changed mid-game (Closes #99)
- fix bug of events not being translated when locale changes in-game (Closes #128)
- fix bug of --singledir argument being ignored
- sort saved games list in in-game load game dialog
- use ~/.config/singularity for preferences dir
- use ~/.local/share/singularity/music as an additional source for music
And, of course, ths most important one:
- added Brazilian Portuguese (pt_BR) translation
I tried to be as verbose as possible in my commit messages, so all info and rationale is there. Changelog is also upsdated in each commit, with a brief, user-oriented explanation of the change.
I am now ready to do bolder changes, including using more translatable strings (many of them already listed in strings_en_US.dat, but not yet used in game), and a welcome refactoring and code cleanup. But before that I need some feedback on the above changes. What should my expectations be?
Last but not least, I didn't dare to change AUTHORS file or [Credits] section in README. I leave that to your discretion.
Thanks,
Rodrigo
Phil Bordelon
> Hi there again Phil!
[snip]
> I am now ready to do bolder changes, including using more translatable
> strings (many of them already listed in strings_en_US.dat, but not yet used
> in game), and a welcome refactoring and code cleanup. But before that I need
> some feedback on the above changes. What should my expectations be?
>
> Last but not least, I didn't dare to change AUTHORS file or [Credits]
> section in README. I leave that to your discretion.
Rodrigo,
Sorry. Life got busy. I will find time this week (and hopefully in the
next day or two) to check out your changes.
P
Phil Bordelon
> Hi there again Phil!
Hey. So, first, I think you need to join the -dev mailing list.
Secondly, I've merged two of your changes so far (the
.gitignore/.gitsettings one, and the trivial-but-essential
reload-of-techs one). I was looking at your singledir changes,
but git log showed me that the code has extraneous tabs in
blank lines (i.e. the Big Red Mark). I realize that this might seem
nitpicky, but would you mind cleaning those up in any/all extant branches
and letting me know so that I can look at those and potentially
merge them directly, rather than having to edit the patches myself?
Thanks.
My first-blush response is that I'll probably take all of the non-XDG
ones, and will have to think about the XDG stuff, mainly for compatibility
reasons. (I haven't had enough time to actually look at the patch to see
if it actually handles my concerns re: compatibility.)
Anyway, let me know, and thanks again.
P
MestreLion
On Monday, March 12, 2012 10:40:24 AM UTC-3, Phil Bordelon wrote:
On 03/12/2012 07:53 AM, MestreLion wrote:
> Hi there again Phil!Hey. So, first, I think you need to join the -dev mailing list.
I would be glad to. But... how can I? It is a moderated list, so I think you need to add me to members.
Secondly, I've merged two of your changes so far (the
.gitignore/.gitsettings one, and the trivial-but-essential
reload-of-techs one).
I was looking at your singledir changes,
but git log showed me that the code has extraneous tabs in
blank lines (i.e. the Big Red Mark). I realize that this might seem
nitpicky, but would you mind cleaning those up in any/all extant branches
and letting me know so that I can look at those and potentially
merge them directly, rather than having to edit the patches myself?
Thanks.
Sorry for those. I'll try to fine-comb the other commits so no one is left. Should I re-build the main branch for you to pull a clean code?
My first-blush response is that I'll probably take all of the non-XDG
ones, and will have to think about the XDG stuff, mainly for compatibility
reasons. (I haven't had enough time to actually look at the patch to see
if it actually handles my concerns re: compatibility.)
Anyway, let me know, and thanks again.
Rodrigo
Phil Bordelon
> I would be glad to. But... how can I? It is a moderated list, so I think
> you need to add me to members.
It's only moderated for non-members. Anyone can join. You shouldn't
have any issue hitting the 'Join' button here:
http://groups.google.com/group/endgame-singularity-dev
via "edit my membership".
> Glad to hear. The sort-load-games is also trivial-but-annoying, and
> fix-events-translations is almost-trivial-and-very awkward
I had already incorporated sort-load-games. I'll take a look at the
rest later.
> Sorry for those. I'll try to fine-comb the other commits so no one is left.
> Should I re-build the main branch for you to pull a clean code?
See below.
>> My first-blush response is that I'll probably take all of the non-XDG
>> ones, and will have to think about the XDG stuff, mainly for compatibility
>> reasons. (I haven't had enough time to actually look at the patch to see
>> if it actually handles my concerns re: compatibility.)
>>
> I agree that both xdg ones are a bit bold move. But, as stated in the
> commit messages, they are 100% backwards-compatible: if user already has
> ~/.endgame folder, ignore xdg and use it. Same for ~/.endgame/music. So
> this change will actually only affect new installs.
That's good. Assuming it passes muster, I'll pull it in as well.
> About "presentation", what do you want? A single, good-looking, rebased
> "main" branch with 1-feature-per-commit, or the ugly feature branches
> themselves? I assumed the "main" branch would suit you better, specially
> because of the fewer commits, more verbose commit messages, and linear
> history. Just tell me wour favorite layout and I'll do so.
Looks like you get to be the git workflow guinea pig for us. Sorry
about that :)
How about a cross between the two? Single-commit rebased feature
branches. Feel free to keep the actual implementation feature branches
available for people to poke through--myself included--but for actual
merging a single commit is nicer. You could name them something like
feature and feature_tomerge, but whatever, they're just names. I'd
rather a cleaner history on the upstream than what we will all have
internally, though. Not that I care so much as to back out the changes
I've already incorporated, mind :)
I don't care about linear history (one of the reasons I switched to
Git in the first place).
P
Phil Bordelon
> It's only moderated for non-members. Anyone can join. You shouldn't
> have any issue hitting the 'Join' button here:
>
> http://groups.google.com/group/endgame-singularity-dev
>
> via "edit my membership".
Note to self: I was wrong here. We were having a spam issue at some
point and switched to default-moderated. You should be able to post
just fine now, Rodrigo.
P
MestreLion
Anyway, now that we got already "acquainted", and you seem to be very open and willing to let most (if not all) my contributions go in, I know I can move forward in fully translating E:S. My girlfriend loves the game, and she is my main motivation for this endeavor.
As for being a git guinea pig, I don't mind at all. I'm new to git scene, and to FOSS contributions in general, so I'm also learning and testing different workflows / repo structures. But, until we find the best "format" for this, wouldn't it be better if you roll back all the changes in master branch? That is a public, official, reference branch for E:S, and we'd better not "spoil" it with our tests.
We can then take our time and try different merge / rebase / cherry-pick strategies in a new, say "test" branch. You pull my work there, so I can see the results, and when you're glad with it, merging with original "master" will be a simple fast-forward.
Meanwhile, as promised, I'll re-do my "main" branch so no "Big Red Markers" are there. I've finally tamed Eclipse/PyDev for that :D. I'll also create another branch. "main' will be a linear, rebased, good-looking branch, while "main-merge" will use a more traditional (but ugly) merge approach.
My issue with merge-branches are not only aesthetics: feature branches are meant to be private and temporary. I commit very often, and those branches are my "scrap" area. Once their changes are incorporated, they can be even deleted, or archived (meaning pushed to my backup repo, and deleted from my "presentation" one)
I'm talking too much already... anyway, those changes will take a few days, and I'll send a note whenever they are ready. Meanwhile , please revert the changes in official master branch.
Oh, last but not least: did you notice I've tagged all E:S release commits? those tags are surely be worth retrieving, if not, for "historical" reasons :)
Also I'm glad the moderation issue was solved.. I was thinking I was doing something wrong... :)
Cya,
Rodrigo
Phil Bordelon
> Sorry for being absent in the last couple of days... emergency at work :(
No problem. I know what those are like.
> Anyway, now that we got already "acquainted", and you seem to be very open
> and willing to let most (if not all) my contributions go in, I know I can
> move forward in fully translating E:S. My girlfriend loves the game, and she
> is my main motivation for this endeavor.
Awesome.
> As for being a git guinea pig, I don't mind at all. I'm new to git scene,
> and to FOSS contributions in general, so I'm also learning and testing
> different workflows / repo structures. But, until we find the best "format"
> for this, wouldn't it be better if you roll back all the changes in master
> branch? That is a public, official, reference branch for E:S, and we'd
> better not "spoil" it with our tests.
The changes so far in master aren't worth rolling back. Two were
single-commit fixes, and the third, yeah, took three commits, but who cares?
They're all changes that need to get done.
> We can then take our time and try different merge / rebase / cherry-pick
> strategies in a new, say "test" branch. You pull my work there, so I can see
> the results, and when you're glad with it, merging with original "master"
> will be a simple fast-forward.
That's probably worth doing. Call it "git_test", if you please.
> Meanwhile, as promised, I'll re-do my "main" branch so no "Big Red Markers"
> are there. I've finally tamed Eclipse/PyDev for that :D. I'll also create
> another branch. "main' will be a linear, rebased, good-looking branch, while
> "main-merge" will use a more traditional (but ugly) merge approach.
>
> My issue with merge-branches are not only aesthetics: feature branches are
> meant to be private and temporary. I commit very often, and those branches
> are my "scrap" area. Once their changes are incorporated, they can be even
> deleted, or archived (meaning pushed to my backup repo, and deleted from my
> "presentation" one)
Which is why I suggested that you have a merge branch rather than a feature
branch. You tinker with it all you want in a feature branch--taking as many
commits as you want--and then once you've got it working, make a second
branch which has the exact same changes as a single commit (basically a
rebase). I then merge that second branch. That won't keep you from pushing
those branches away from your own repo.
> I'm talking too much already... anyway, those changes will take a few days,
> and I'll send a note whenever they are ready. Meanwhile , please revert the
> changes in official master branch.
>
> Oh, last but not least: did you notice I've tagged all E:S release commits?
> those tags are surely be worth retrieving, if not, for "historical" reasons :)
Actually, I had tagged them too (well, svn2git had), but I forgot that git
doesn't push tags upstream by default. Derp. Glad you did it as well, but
that's why I didn't notice--I had them already :)
> Also I'm glad the moderation issue was solved.. I was thinking I was doing
> something wrong... :)
Thanks again.
P
MestreLion
> We can then take our time and try different merge / rebase / cherry-pick
> strategies in a new, say "test" branch. You pull my work there, so I can see
> the results, and when you're glad with it, merging with original "master"
> will be a simple fast-forward.That's probably worth doing. Call it "git_test", if you please.
> My issue with merge-branches are not only aesthetics: feature branches are
> meant to be private and temporary. I commit very often, and those branches
> are my "scrap" area. Once their changes are incorporated, they can be even
> deleted, or archived (meaning pushed to my backup repo, and deleted from my
> "presentation" one)Which is why I suggested that you have a merge branch rather than a feature
branch. You tinker with it all you want in a feature branch--taking as many
commits as you want--and then once you've got it working, make a second
branch which has the exact same changes as a single commit (basically a
rebase). I then merge that second branch. That won't keep you from pushing
those branches away from your own repo.
topic/* - my private, multi-commit topic branches. Not pushed to my public repo
publish/* - single-commit branches, rebased from topic/*, ready to merge to your 'master'
master - a branch originated from your 'master', with all my publish/* branches already merged in. Just a commodity for you in case you like all my changes, you can simply merge this one (will be resolved as a fast-forward) instead of individually merging all the publish/* branches one by one.
Is that it?
If there are any more branches / layouts you want to try, just tell me. Also suggestions about nomenclature are welcome (I admit 'publish' is a little lame)
> Oh, last but not least: did you notice I've tagged all E:S release commits?
> those tags are surely be worth retrieving, if not, for "historical" reasons :)Actually, I had tagged them too (well, svn2git had), but I forgot that git
doesn't push tags upstream by default. Derp. Glad you did it as well, but
that's why I didn't notice--I had them already :)
http://code.google.com/r/rodrigosilva-singularity/
The previous one will soon be deleted.
Cya,
ML
Phil Bordelon
> That's probably worth doing. Call it "git_test", if you please.
>
> Me? I'm not sure if I'm following... this test branch will only exist in
> your repo, isn't it?
Er, yes. Don't mind me :)
> Ok, let's see if I understood correctly... here is my new branching
> nomenclature:
>
> topic/* - my private, multi-commit topic branches. Not pushed to my public repo
> *publish/** - single-commit branches, rebased from topic/*, ready to merge
> to your 'master'
> *
> master* - a branch originated from your 'master', with all my publish/*
> branches already merged in. Just a commodity for you in case you like all my
> changes, you can simply merge this one (will be resolved as a fast-forward)
> instead of individually merging all the publish/* branches one by one.
>
> Is that it?
Yup, precisely.
> If there are any more branches / layouts you want to try, just tell me. Also
> suggestions about nomenclature are welcome (I admit 'publish' is a little lame)
private/ and public/ are easy names. Dunno how you feel about them.
> Push --tags them to the public repo, so future clones will already have them
> in. I'm also curious to know if I tagged mine correctly...
> Last but not least, don't forget my public repo changed to:
> *http://code.google.com/r/rodrigosilva-singularity/*
Tags pushed. I checked a few of the ones you made; most were the right
commit, some were a rev or so off.
> The previous one will soon be deleted.
Yeah, I've already switched.
P