Ideas for complete i18n

[MestreLion]

Hi there Phil, how are you? It's been a while, but now I'm back :)

The first batch of changes are good to go, have you merged them yet? As you requested: several 1-commit branches named public/* and a "already merged" one called master

With the "easy" stuff done, now I'm ready for more bold changes. Namely, complete internationalization of E:S, ie, the changes necessary to make all strings in E:S are translatable.

Carefully reading the source code and the data/strings* files, I have some insights on the best approach to do that. I would like to share those with you, and have your opinion and feedback before doing the necessary "revamp" on code.

- The current approach of "all ordinary strings maps to an arbitrarily named vars in data/strings_en_US.dat" is, IMHO, unmaintainable. There are literally hundreds of small text strings in source code, mostly button labels. Creating a new var/value pair in strings.dat for each string in code is a huge burden, and I believe it is one of the reasons full i18n wasn't done yet. Naming the vars would also pose a problem, even if we try to "standardize" it, or create "namespaces" (button_xxx, label_yyy, etc)

- I would like to propose the gettext approach to E:S: entries are "named" after their original US English content. So, for example in button.FunctionButton(... , text="LOAD GAME", ...) , instead of text=g.strings["load_game"] (and a corresponding entry in strings_en_US.dat) we would have button.FunctionButton(... , text=_("LOAD GAME"), ...) , where "_" is the translation function (more on that later). The point is, no need to create a var for each string... just replace each currently hardcoded string for _("...") and let the translation function do its magic. It can be as verbose as _("Are you sure you want to destroy this base?") or as complex as _("DAY %04d, %02d:%02d:%02d"). Can't be easier than that!

- The translation function would work this way: For backward-compatibility with current strings entries, _("some_text") would first check if g.strings["some_text"] exists. If yes, it is used. If not, it would look for a matching msgid entry in current locale's data/xx_XX.po file. If not found, it would fallback to be "translated" as a literal "some_text". Notice that there is no need for a en_US.po file: the fallback english translation is already hardcoded in the source code function call argument. Any string can be made translatable without touching current data/* files.

- Notice I am not suggesting for us to use GNU's gettext / lib/gettext.py for now, only its approach. Handling .po files, messages.pot, compiling to .mo, etc, can a burden right now, and current data/* files are still convenient, specially for "true data" files techs, locations, bases, items etc. But for strings, we could mimic gettext's behavior, borrow its best ideas and implement our own customized version of "_()".

- If, and only if, we decide in the future to actually switch to gettext and use its libraries, changes to code would be minimum, since all strings would already be the format gettext requires. We would probably only need to import it in headers and delete our customized _() function, and it will be done already.

- Even if not using gettext library, since we are mimicking its behavior we could use its tools to parse the source code and generate the template files for us.Much better than maintaining a strings_en_US.dat manually.

- Another problem is keyboard shortcuts: most of the hotkeys in data/strings_en_US.dat are not used in code, the xxx_hotkey naming scheme is hard to maintain, and currently many hotkeys found in data/locations_xx_XX.dat are broken and collide with other existing buttons. And having a separate entry for hotkeys is unfeasible with the proposed approach. So I suggest this: to embed the hotkey info in the string itself! Again, GUI/Menu-style, using "&" for hotkeys: "&LOAD GAME" -> L, "E&UROPE" -> U, and so on. For literal &, use &&, as in "Command && Con&quer" -> q.

- Hotkeys would be used like this example: button.ExitDialogButton(... text=_("&BACK"), hotkey=_("&BACK",true), ...). It would parse the translated string and return the appropriate char, or 1st char if none is found. _()'s 2nd and optonal parameter would be a flag for hotkey usage. The default would be which would strip non-literals &s after translating the string. The result would be text="BACK", hotkey="B" for en)US locale, and, if there is a matching msgid="&BACK" / msgstr="&VOLTAR" entry in pt_BR.po, it would result in text="VOLTAR", hotkey="V"

- So far, all my proposed changes affects strings only, but this new hotkeys approach is worth consider implementing in data/location_xx_XX.dat files as well. Maybe not now but in the near future. Would only require a minor change from

[EUROPE]
name = EUROPE
hotkey = u
cities_list = ...

to

[EUROPE]
name = &EUROPE
cities_list = Cork | Barcelona | Athens | Utrecht | Moscow | Tel Aviv | Reykjavik | Liechtenstein

And, of course, adjusting g.load_location_defs() accordingly

- Last but not least,  an optional but interesting insight for hotkeys is to add a parameter called "domain", which help help mapch which screens use which hotkeys. Something like hotkey=_("&BACK",true,"finance") The translation function could maintain a run-time list of the hotkeys assigned per domain, avoiding conflicts when adding a new hotkey to the same domain (for example, returning the 2nd letter instead of the 1st, or the 3rd, 4th, etc, until a non-used letter is found). If the generator used to create the template .po file could also scan for the domains, we could have something like:

# Used by: finance, options, menu, research
msgid "&BACK"
msgstr "&VOLTAR"

Or the reverse:

# menu hotkeys:
# "&NEW GAME"
# "&LOAD GAME"
# "&SAVE GAME"
# "&BACK"
# "&QUIT"

Which would considerably help translators not to assign conflicting letters for buttons used on same screen. This is a quite an ambitious feature, but one worth investigating

Wow, that was a long email... But I would love to hear your opinion, suggestions and feedback on all of these ideas... what do you think about all of this?

Regards,
ML

[Phil Bordelon]

On 03/28/2012 11:06 AM, MestreLion wrote:
> Hi there Phil, how are you? It's been a while, but now I'm back :)
>
> The first batch of changes are good to go, have you merged them yet? As you

> requested: several 1-commit branches named *public/** and a "already
> merged" one called *master*

I haven't; I was waiting for you to ping me letting me know they were
ready to go. (One problem with Google Code is that it doesn't have the
whole "pull request" system that Github does.) Now that you have, I'll
take a look at them this evening.

> With the "easy" stuff done, now I'm ready for more bold changes. Namely,
> complete internationalization of E:S, ie, the changes necessary to make all
> strings in E:S are translatable.

-snip-

I've never been convinced (but that can of course change :) that
gettext-style localization is really that much of a win. I get
that it's easier from a programming perspective, but it's always
seemed like a nasty mash-up of "display" and "logic" that's just
never sat well with me. I don't consider it that much of a burden
(from a programming perspective) for all of the button labels, etc.
to be pointers to something in a data file rather than just spelled
out directly in the source.

One of the real problems I have with gettext-style approaches is that
it's completely beholden to the original source language. In other
words, if I want to change the in-game English text, that screws up all
the other translations until their mappings are adjusted. That bothers
me from an ethnocentric viewpoint, but maybe I'm overly sensitive to
these sorts of things.

That, plus the whole "hardcoded strings in the source file," make me
want to steer away from gettext-style solutions. For me, the optimal
result is that we have a codebase where people could change any of the
text they want--English, German, Portugese--without ever editing a
Python source file. But, like I said, I can potentially be convinced
otherwise.

> - Another problem is keyboard shortcuts: most of the hotkeys in
> data/strings_en_US.dat are not used in code, the xxx_hotkey naming scheme
> is hard to maintain, and currently many hotkeys found in
> data/locations_xx_XX.dat are broken and collide with other existing
> buttons. And having a separate entry for hotkeys is unfeasible with the

> proposed approach. So I suggest this: *to embed the hotkey info in the
> string itself! *Again, GUI/Menu-style, using "&" for hotkeys:"&LOAD GAME"

> -> L, "E&UROPE" -> U, and so on. For literal&, use&&, as in "Command&&
> Con&quer" -> q.

This embedding could be done in the current approach, it's just not the
way it's handled. I have no problem with us changing the current data
file format to do it this way rather than having a foo_hotkey = entry in
the .dat file.

[-snipped discussion of hotkey domains-]

> Wow, that was a long email... But I would love to hear your opinion,
> suggestions and feedback on all of these ideas... what do you think about
> all of this?

I think that complete localization of the game is a /very good/ goal,
and I'm happy to work with you on making that happen. I just think
we need to go about it in a way that ends up being maintainable and
doesn't offend everyone's sensibilities too much. :)

I snipped the hotkey domain stuff because I think it's a neat idea, but
it also smells of a "code black hole"--a feature whose utility is
outweighed by the maintenance burden it inflicts. It wouldn't be hard
for the hotkey-registration function on each screen to complain (perhaps
even with a dialog, so it can't be missed in the text log) when two
buttons try to register the same hotkey. That would catch the problem
quickly and with a lot less of a long term maintenance burden. If E:S
were a traditional roguelike, with a billion-zillion hot keys for doing
everything, it might be worth it... but there really just aren't that
many.

P

[MestreLion]

On Wednesday, March 28, 2012 3:08:43 PM UTC-3, Phil Bordelon wrote:

I've never been convinced (but that can of course change :) that
gettext-style localization is really that much of a win.  I get
that it's easier from a programming perspective, but it's always
seemed like a nasty mash-up of "display" and "logic" that's just
never sat well with me.  I don't consider it that much of a burden
(from a programming perspective) for all of the button labels, etc.
to be pointers to something in a data file rather than just spelled
out directly in the source.

One of the real problems I have with gettext-style approaches is that
it's completely beholden to the original source language.  In other
words, if I want to change the in-game English text, that screws up all
the other translations until their mappings are adjusted.  That bothers
me from an ethnocentric viewpoint, but maybe I'm overly sensitive to
these sorts of things.

That, plus the whole "hardcoded strings in the source file," make me
want to steer away from gettext-style solutions.  For me, the optimal
result is that we have a codebase where people could change any of the
text they want--English, German, Portugese--without ever editing a
Python source file.  But, like I said, I can potentially be convinced
otherwise.

You've raised some very interesting points I didn't think about before . Let me try to summarize all our issues and concerns about i18n so can find a common solution that solves all (or most) of them:

A) Current approach requires programmer to edit translation (data) files for ordinary strings
B) Code gets "messy" with data instead of pure logic
C) gettext approach requires translator to edit source code for English changes
D) Any change in English strings in source would invalidate all other translations

Any others?

Don't underestimate (A): it is not simply about creating an entry in strings_en_US.dat, one must also *name it* appropriately. For long sentences like "Are you sure you want to destroy this base?" this requires some undesirable "creativity" from the programmer. ("destroy_base_confirmation"? "base_delete_msg"?). And this burden is perhaps the (or one of the major) reason why more than a hundred strings are currently not only untranslated but *untranslatable* in E:S

But I agree: C) and D) are huge issues, and no, you're not being oversensitive.

So, how about this? Let's create a en_US.po too! This way we properly separate 2 distinct concepts: the "programmer's meaning intention for a string", and the "English translation of that string". Since for short strings like "Save Game" this ends up being called g.strings["save_game"], gettext approach only takes this a step further by automatically naming the pointers to the strings, any string. But it would still be just a pointer, a programmer's message to the translators indicating the intended meaning of that string, NOT the "official English translation" of that string. Just a pointer that also doubles as the last fallback.

This would solve (C). If you want to customize (or improve) the English text, change en_US.po only. No need to touch the source code anymore. And would solve (D) too: the string in source code is unchanged, so all current translations are still valid.

This way, English language (or any *_en_US.dat/po) is no longer "above" other languages. It will be just one more language, which may or may not be used as a fallback. _() could search for xx_XX.po > en_US.po > hardcode or simply xx_XX.po > hardcode. The hardcoded string just happen to be expressed in English, but it could be any language the translators understand and agree to work with. It would not be related in any way with en_US.

This concept also (kinda) solves (B). Think of the hardcoded strings as the current "keys/pointers" in g.strings . Only instead of "save_game" we would have "&SAVE GAME". And if *that* string changes, then yes, it would invalidate all translations, but that's intentional, because it means the programmer's *meaning* for that string have changed too, and thus translations *must* be changed to reflect the new meaning.  Think of the "Are you sure to destroy this base?" example. What if the programmer changed to "Are you sure you want to disable this base?". There is an implicit change in *logic*, bases are not *deleted* anymore but simply "disabled". Current translations are supposed to be invalidated. "Tem certeza que deseja destruir essa base?" is no longer an acceptable translation for that game logic. So the "messy" hardcoded strings are still a pointer to a data file, but now it is a pointer with a precise context and meaning.

> - Another problem is keyboard shortcuts: most of the hotkeys in
> data/strings_en_US.dat are not used in code, the xxx_hotkey naming scheme
> is hard to maintain, and currently many hotkeys found in
> data/locations_xx_XX.dat are broken and collide with other existing
> buttons. And having a separate entry for hotkeys is unfeasible with the
> proposed approach. So I suggest this: *to embed the hotkey info in the
> string itself! *Again, GUI/Menu-style, using "&" for hotkeys:"&LOAD GAME"
> ->  L, "E&UROPE" ->  U, and so on. For literal&, use&&, as in "Command&&
> Con&quer" ->  q.

This embedding could be done in the current approach, it's just not the
way it's handled.  I have no problem with us changing the current data
file format to do it this way rather than having a foo_hotkey = entry in
the .dat file.

Nice! I'll change g.load_strings_defs() and load_locations_defs() accordinly. It will parse foo string for "&"s and auto assign foo_hotkey. For full backwards-compatibility, it will only auto-assign if foo_hotkey is currently empty, and if later there is a foo_hotkey in data file, it will overwrite the "&" auto assigned value.
 

[-snipped discussion of hotkey domains-]

> Wow, that was a long email... But I would love to hear your opinion,
> suggestions and feedback on all of these ideas... what do you think about
> all of this?

I think that complete localization of the game is a /very good/ goal,
and I'm happy to work with you on making that happen.  I just think
we need to go about it in a way that ends up being maintainable and
doesn't offend everyone's sensibilities too much. :)

I snipped the hotkey domain stuff because I think it's a neat idea, but
it also smells of a "code black hole"--a feature whose utility is
outweighed by the maintenance burden it inflicts.  It wouldn't be hard
for the hotkey-registration function on each screen to complain (perhaps
even with a dialog, so it can't be missed in the text log) when two
buttons try to register the same hotkey.  That would catch the problem
quickly and with a lot less of a long term maintenance burden.  If E:S
were a traditional roguelike, with a billion-zillion hot keys for doing
everything, it might be worth it... but there really just aren't that
many.

P

About domains, I agree that it may be too much trouble for little gain. It was just an idea. Is there any way, using current E:S "technology", to list all the keys used in a given screen? I don't know how the button widgets work. Do we need to create a "hotkey registration" function, or does pygame/button widgets already maintain a list for each dialog? If we need to create one, how would it know which "screen" each hotkey belongs to? The domain idea was exactly a "fancy" name to list the buttons used in each screen. If pygame automatically provides this somehow, great! :D

But let's keep hotkey conflicts to the log file... it is meant for devs only, no need to disrupt user if data files are "broken". And translator could be educated to test translations by opening each screen (which they probably already do) and then look at the log file. --cheat mode would also be required, because some locations (and thus hotkeys) are only accessible late-game, so conflict may not be immediately obvious.

Last but not least, I'm *very* glad you think that full internationalization is a great goal, and I'll be honored to help make it work.

Eager to read your comments,
ML

[Phil Bordelon]

First, apologies: I meant to look at the Git stuff last night, and
did not. It probably won't happen tonight either, as I have a D&D
game, but it /will/ happen this weekend.

On 03/29/2012 10:09 AM, MestreLion wrote:
> Don't underestimate (A): it is not simply about creating an entry in
> strings_en_US.dat, one must also *name it* appropriately. For long
> sentences like "Are you sure you want to destroy this base?" this requires
> some undesirable "creativity" from the programmer.
> ("destroy_base_confirmation"? "base_delete_msg"?). And this burden is
> perhaps the (or one of the major) reason why more than a hundred strings
> are currently not only untranslated but *untranslatable* in E:S
>
> But I agree: C) and D) are huge issues, and no, you're not being
> oversensitive.
>
> So, how about this? Let's create a en_US.po too! This way we properly
> separate 2 distinct concepts: the "programmer's meaning intention for a
> string", and the "English translation of that string". Since for short
> strings like "Save Game" this ends up being called g.strings["save_game"],
> gettext approach only takes this a step further by automatically naming the
> pointers to the strings, any string. But it would still be just a pointer,
> a programmer's message to the translators indicating the intended meaning
> of that string, NOT the "official English translation" of that string. Just
> a pointer that also doubles as the last fallback.

The thing is, this is really just syntactic sugar on A). What is the
meaningful difference between having to come up with a name like
"destroy_base_confirmation" and having a line in the code that's
_("Really destroy base?") that still has to be "translated" into smooth
English?

I am curious as to what you think are currently /untranslatable/ strings
in the code. A couple of examples of "tough lines" that we can work on
hashing out will take this from theoretical to practical, which I think
would be a good thing.

> Nice! I'll change g.load_strings_defs() and load_locations_defs()
> accordinly. It will parse foo string for "&"s and auto assign foo_hotkey.
> For full backwards-compatibility, it will only auto-assign if foo_hotkey is
> currently empty, and if later there is a foo_hotkey in data file, it will
> overwrite the "&" auto assigned value.

Makes sense.

> About domains, I agree that it may be too much trouble for little gain. It
> was just an idea. Is there any way, using current E:S "technology", to list
> all the keys used in a given screen? I don't know how the button widgets
> work. Do we need to create a "hotkey registration" function, or does
> pygame/button widgets already maintain a list for each dialog? If we need
> to create one, how would it know which "screen" each hotkey belongs to? The
> domain idea was exactly a "fancy" name to list the buttons used in each
> screen. If pygame automatically provides this somehow, great! :D

It's been ages since I've looked at the interface code, and FM changed
it pretty significantly from the last time I looked at it, but hotkeys
have to be registered /somewhere/ for them to be captured by the input
loop, so there's got to be a spot where we can check for duplicates (if
it's not already being done).

> Last but not least, I'm *very* glad you think that full
> internationalization is a great goal, and I'll be honored to help make it
> work.

It is my belief that, in this day and age, an untranslatable game (or
piece of code) is a dead game.

> Eager to read your comments,
> ML

P

[MestreLion]

Em quinta-feira, 29 de março de 2012 12h18min48s UTC-3, Phil Bordelon escreveu:

First, apologies: I meant to look at the Git stuff last night, and
did not.  It probably won't happen tonight either, as I have a D&D
game, but it /will/ happen this weekend.

No apologies needed. You already said you were OK with those changes, and we agreed about *how* those changes should be presented/published/merged. As for *when*, it doesn't matter to me, so take your time.
 

The thing is, this is really just syntactic sugar on A).  What is the
meaningful difference between having to come up with a name like
"destroy_base_confirmation" and having a line in the code that's
_("Really destroy base?") that still has to be "translated" into smooth
English?

There /is/ a difference when we are talking about dozens (perhaps hundreds) of little text snippets. Coming up with names like "destroy_base_confirmation" is /boring/, and sometimes tricky, for a developer. Since many will be referenced almost verbatim (like "Save Game" -> "save_game"), why /requiring/ devs to edit strings_en_US.dat for each string found on code? Why a dev must worry if a given sentence is already used somewhere else on code and use the appropriate pointer?

True, I agree that this is actually just syntactic sugar, but I think it really makes development easier and more flexible. No need to edit strings.dat side by side with code. No need to come up with names or look them up all the time. That's twice the effort for a task that is already very time-consuming.

And remember those strings don't /need/ to be "translated to smooth English". strings_en_US.dat/po is not *necessary*. I am just providing a way to change English translations without editing source code .py files, as (C) is a fair concern, and without interfering with other translations (D).

So it's syntactic sugar that makes dev' s lives a lot easier and does not hinder translators at all. It's a win-win :D
 

I am curious as to what you think are currently /untranslatable/ strings
in the code.  A couple of examples of "tough lines" that we can work on
hashing out will take this from theoretical to practical, which I think
would be a good thing.

Fair approach. I will divide them in 2 groups: the "tough/tricky" ones, and the "silly" ones:

Tricky (A.K.A. "how the hell should I name these?)
code/screens/map.py:520 self.time_display.text = "DAY %04d, %02d:%02d:%02d" % \
code/screens/map.py:639 cash_amount = g.create_textbox("How much cash?", "", g.font[0][18],
code/screens/map.py:337 text="Enter a name for this save.")
code/screens/base.py:98  text="Completion in 15 hours.", bold=True)
code/screens/knowledge.py:150-159:  desc_text += "Study far away from this planet."

(Last one was naming it "danger_3" means nothing to a translator... he would need the strings_en_US/source code to understand it, which is not very sensitive if we are trying to make E:S culturally "agnostic")

Silly ones (A.K.A. "Why the hell can't they name after themselves automatically?")
Concepts
Techs
Research Cost:\n
Research complete.
Items
CPU bonus:
LOAD GAME
SAVE GAME
Fullscreen
Resolution
VERY EASY
EASY
NORMAL
HARD
News
Covert
Public
...
the list is long :)

There is also another argument you may find appealing: unlike techs, bases, locations, etc  that have an agnostic "reference" file, strings currently *depend* on strings_en_US.dat  as the "oficial" reference for the available strings. There is no "strings.dat" that lists all the keys used in code. So currently string handling /is/ very ethnocentric. And we have no means to scan and list all string keys used in code, besides keeping a manually updated strings_en_US.dat, a very error-prone task (specially since many of the strings there are /not/ being used in code!)

The gettext approach solves this 2 issues (besides the "useless double effort" for the "silly" strings): it makes strings_en_US.dat no longer more important than any other translation file. It's not the one-and-only reference anymore, it is optional and can be deleted just like the others. And it also provides a way to, using gettext's tools, parse the source code and generate the mapping reference file (usually messages.pot, but it we can name it anything, like "strings.dat") We can't automatically generate such list with current key/value approach.

I hope the "win-win with no cons" argument before and this one are suductive enough, because I'm running out of good arguments :)

> About domains, I agree that it may be too much trouble for little gain. It

> was just an idea. Is there any way, using current E:S "technology", to list
> all the keys used in a given screen? I don't know how the button widgets
> work. Do we need to create a "hotkey registration" function, or does
> pygame/button widgets already maintain a list for each dialog? If we need
> to create one, how would it know which "screen" each hotkey belongs to? The
> domain idea was exactly a "fancy" name to list the buttons used in each
> screen. If pygame automatically provides this somehow, great! :D

It's been ages since I've looked at the interface code, and FM changed
it pretty significantly from the last time I looked at it, but hotkeys
have to be registered /somewhere/ for them to be captured by the input
loop, so there's got to be a spot where we can check for duplicates (if
it's not already being done).

True. I'm not familiar with interface code either, but I'll try to investigate that. It will be sweet to have a "hotkey monitor" to monitor dupes and log them :)
 
ML

[Phil Bordelon]

On 03/29/2012 01:17 PM, MestreLion wrote:

> I hope the "win-win with no cons" argument before and this one are
> suductive enough, because I'm running out of good arguments :)

I think you've convinced me. Congratulations!

This is not going to be fun work to transition to, alas.

> True. I'm not familiar with interface code either, but I'll try to
> investigate that. It will be sweet to have a "hotkey monitor" to monitor
> dupes and log them :)

Good luck. If I get a chance this weekend I'll do some digging myself.

P

[Phil Bordelon]

On 03/29/2012 01:17 PM, MestreLion wrote:

> No apologies needed. You already said you were OK with those changes, and
> we agreed about *how* those changes should be presented/published/merged.
> As for *when*, it doesn't matter to me, so take your time.

I merged fix_events_translating, respect_singledir, and
translation_pt_BR. I'm still a little leery of the XDG patches,
particularly the one that does some funny things with symlinks.

Please submit a patch for AUTHORS giving yourself whatever name you
want documented there, and send me (under separate cover) the precise
Gmail account you want me to grant commit access to for the Gcode
project.

Thanks for your work!

P

[MestreLion]

Em quinta-feira, 29 de março de 2012 15h29min12s UTC-3, Phil Bordelon escreveu:

On 03/29/2012 01:17 PM, MestreLion wrote:

 > I hope the "win-win with no cons" argument before and this one are
 > suductive enough, because I'm running out of good arguments :)

I think you've convinced me.  Congratulations!

Thanks! And I hope you're saying that because you truly liked the points given, /not/ because you think that "If I don't say yes this annoying guy will keep arguing" :P

This is a big design decision, so take you time if you want to think more about it.
 

This is not going to be fun work to transition to, alas.

Agreed. Translations and internationalization are always a pain to implement, specially with mature code. But I /promise/ I'll do that as trouble-free as possible. A good commitment to that is: not a single byte of data/*_xx_XX.dat will need to be changed to make my proposal work. 100% full backward compatibility, as with all the other patches I've sent you so far.
 

> True. I'm not familiar with interface code either, but I'll try to
> investigate that. It will be sweet to have a "hotkey monitor" to monitor
> dupes and log them :)

Good luck.  If I get a chance this weekend I'll do some digging myself.

P

It will be a fun weekend! :D

And good D&D tonite!

ML

[Phil Bordelon]

On 03/29/2012 02:09 PM, MestreLion wrote:

> Thanks! And I hope you're saying that because you truly liked the points
> given, /not/ because you think that "If I don't say yes this annoying guy
> will keep arguing" :P
>
> This is a big design decision, so take you time if you want to think more
> about it.

I meant it genuinely. Damn the Internet for making dry sarcasm and
genuine belief basically indistinguishable nowadays.

P

[MestreLion]

Em quinta-feira, 29 de março de 2012 15h54min09s UTC-3, Phil Bordelon escreveu:

Please submit a patch for AUTHORS giving yourself whatever name you
want documented there, and send me (under separate cover) the precise
Gmail account you want me to grant commit access to for the Gcode
project.

Thanks for your work!

P

Wow, this is a great honor, and I feel flattered.

But I don't think I deserve this, at least not yet. My bugfixes so far were very simple and easy, pt_BR translation was a big effort, but not enough to warrant commit access, and this ambitious i18n proposal is still just ideas on paper.

Lets see how this "code revamp" goes, and If i succeed in this challenge, I will then gladly accept this generous offer.

For now, an entry in Credits section of README.txt is enough. My gf will be thrilled :D

ML
 

[Phil Bordelon]

On 03/29/2012 04:04 PM, MestreLion wrote:

> Lets see how this "code revamp" goes, and If i succeed in this
> challenge, I will then gladly accept this generous offer.
>
> For now, an entry in Credits section of README.txt is enough. My gf will
> be thrilled :D

Fair enough. Let me know how you'd like to be credited there.

P

[MestreLion]

Phil, you may fetch (but don't merge) testing/i18n now.. I did vast changes in code/g.py, among other files, prior to actual i18n, and I would like your feedback before moving on...

There were small bugfixes, a few refactoring/cleanup, and a revamped defs file handling, none actually related to our ambitious new i18n ideas, but they all improve current approach in language handling.

Take a look, do a few tests, and tell me what do you think about them...

Cheers,
ML

[Phil Bordelon]

I haven't had time to actually test this code, but I looked at it and
it didn't seem insane. :)

The tweaks to README and the like seemed noisy without accomplishing a
lot. I suggest tossing that particular patch and I might do some
cleanup myself (Brian Reid should no longer be in AUTHORS, for example,
just in the credits, and I'm not sure why you shifted folks around).

Be Bold(tm). We have revision control for a reason. That said, I'll
try to find some time this coming week|end to look a little more
thoroughly.

P

[MestreLion]

After more than a month of work, 38 files, 4310 insertions and 990 deletions later,

... I proudly announce:

public/i18n is ready to merge :D

Enjoy!
ML

[Phil Bordelon]

Just to let you know, I /will/ be merging this, even though I have some
comments (mainly on the options screen). Fantastic work, by the way. I
messed around quite a bit in Portugese and it all looked fantastic. I am
very, very impressed.

P

[Phil Bordelon]

On 05/05/2012 11:33 PM, Phil Bordelon wrote:

> Just to let you know, I /will/ be merging this, even though I have some
> comments (mainly on the options screen). Fantastic work, by the way. I
> messed around quite a bit in Portugese and it all looked fantastic. I am
> very, very impressed.

Although--I have to admit I found this funny--no Changelog entries? :D

P

[Phil Bordelon]

On 05/05/2012 05:11 AM, MestreLion wrote:

> public/i18n is ready to merge :D
>
> Enjoy!
> ML

Merged.

I need (under separate cover, if desired) your GMail account so I can make
you a committer to the Git repository. Your first task, whether or not you
accept it, is to:

- Add yourself to AUTHORS
- Update your entry in README.txt to one of the "full authors"
- Add the missing Changelog entries

in whichever order you prefer.

I'd say congratulations, but that makes commit access out to be something
rather more mindblowing than it really is. I /will/ say thanks again, for
the hard effort you've put in recently.

P

[MestreLion]

Thanks a lot for your compliments... they mean more to me than you imagine...

As for the Changelogs, that was on purpose... There is an 11th, non-published commit, where I update Changelog, README and AUTHORS, proudly adding myself to the list, if you were kind enough to propose that generous commit access again (and I noticed you were in the next email). I wanted my 1st commit to be such commit, officially joining the dev team :)

ML

[Phil Bordelon]

On 05/06/2012 12:43 AM, MestreLion wrote:
> Thanks a lot for your compliments... they mean more to me than you imagine...
>
> As for the Changelogs, that was on purpose... There is an 11th,
> non-published commit, where I update Changelog, README and AUTHORS, proudly
> adding myself to the list, if you were kind enough to propose that generous
> commit access again (and I noticed you were in the next email). I wanted my
> 1st commit to be such commit, officially joining the dev team :)

As mentioned in the previous eMail, just give me the information I need and
I'll make it happen.

P

[MestreLion]

Sure, sorry for the delay. The 11th commit is ready (you can check it out in https://github.com/MestreLion/singularity/tree/public/welcome )

But, before the merge (that I would like the honor to commit myself), I'm "setting the ground" for the new status. Mostly:
- The google repository you've been pulling from so far has no reason to exist anymore
- I'm setting up a new google account for singularity. The email will probably be "singularity a_t rodrigosilva.com". This will be the email I'll use for all singularity-related stuff. This includes commit info, mailing list, github, etc. Currently it's a mess: I post here as rodrigo.espirito...@google.com, I commit using linu...@rodrigos....com, my github (used so far mostly for backups and testing) used a 3rd email, and so on... I'm trying to fix this and unify this mess
- I'm updating my ~/.gitconfig, /.netrc, github, google, etc, to use the new email
- can you please also add that email to the mailing lists?

Also, could you please (privately if you want to) give a a little "tutorial" on how to manage and properly use the new access? I'm totally unfamiliar with administration, since so far I've only worked with that "push to private repo & ping the owners" workflow, so an "Admin 101" would be handy :)

ML

[Phil Bordelon]

On 05/06/2012 11:13 AM, MestreLion wrote:
> Sure, sorry for the delay. The 11th commit is ready (you can check it out in
> https://github.com/MestreLion/singularity/tree/public/welcome )

So many trees in so many places...

> But, before the merge (that I would like the honor to commit myself), I'm
> "setting the ground" for the new status. Mostly:
> - The google repository you've been pulling from so far has no reason to
> exist anymore

Assuming you don't want a public staging space on Google, yes. (I assume
you'll be using Github for that now?)

> - I'm setting up a new google account for singularity. The email will
> probably be "singularity a_t rodrigosilva.com". This will be the email I'll
> use for all singularity-related stuff. This includes commit info, mailing
> list, github, etc. Currently it's a mess: I post here as
> rodrigo.espirito...@google.com, I commit using linu...@rodrigos....com, my
> github (used so far mostly for backups and testing) used a 3rd email, and so
> on... I'm trying to fix this and unify this mess
> - I'm updating my ~/.gitconfig, /.netrc, github, google, etc, to use the new
> email
> - can you please also add that email to the mailing lists?

Google Groups no longer does 'bulk add', as far as I can tell, so the best I
can do is "invite" that eMail address to the group. You'd still have to go
and join it manually. I suspect it's easier for you to just join the groups
via the web interfaces at:

http://groups.google.com/group/endgame-singularity-dev/

and

http://groups.google.com/group/endgame-singularity/

There shouldn't be any approval needed, but let me know when you've done it
and I'll go make the necessary tweaks.

> Also, could you please (privately if you want to) give a a little "tutorial"
> on how to manage and properly use the new access? I'm totally unfamiliar
> with administration, since so far I've only worked with that "push to
> private repo & ping the owners" workflow, so an "Admin 101" would be handy :)

I'm actually learning this as I go too; I just started working on another
project using Git where commits actually overlap occasionally (gasp!) and
it's forced me to learn quite a bit more about Git workflow.

Anyhow, feel free to start hanging out in irc.oftc.net #singularity (I just
re-added it to my join list) and we'll muddle through together :)

P

[MestreLion]

On Sunday, May 6, 2012 1:35:34 PM UTC-3, Phil Bordelon wrote:

On 05/06/2012 11:13 AM, MestreLion wrote:
> Sure, sorry for the delay. The 11th commit is ready (you can check it out in
> https://github.com/MestreLion/singularity/tree/public/welcome )

So many trees in so many places...

I've always had those 3 (upstream to fetch, my google for my "official announcements", and github as my "private playground"). Github was, until now, a place where I could do anything... mirroring my local tree as a backup, push testing branches, rewrite public history, etc, while google was more a "formal" tree with no public rewrites, only pushing branches that were ready for you to either test or merge.

So now I wont have more trees, but less. It just got easier...

> But, before the merge (that I would like the honor to commit myself), I'm
> "setting the ground" for the new status. Mostly:
> - The google repository you've been pulling from so far has no reason to
> exist anymore

Assuming you don't want a public staging space on Google, yes.  (I assume
you'll be using Github for that now?)

My google clone was only created so I could clone E:S and you could fetch from it. It won't be needed anymore. Github is still useful as a personal cloud backup, scrap/experimental area, and now it can double as a staging area if I have a more "polemic" commit that I want to discuss with you before merge (xdg anyone? :P). Since you and I have github accounts, theres little point in my Google clone now.
 

> - I'm setting up a new google account for singularity. The email will
> probably be "singularity a_t rodrigosilva.com". This will be the email I'll
> use for all singularity-related stuff. This includes commit info, mailing
> list, github, etc. Currently it's a mess: I post here as
> rodrigo.espirito...@google.com, I commit using linu...@rodrigos....com, my
> github (used so far mostly for backups and testing) used a 3rd email, and so
> on... I'm trying to fix this and unify this mess
> - I'm updating my ~/.gitconfig, /.netrc, github, google, etc, to use the new
> email
> - can you please also add that email to the mailing lists?

Google Groups no longer does 'bulk add', as far as I can tell, so the best I
can do is "invite" that eMail address to the group.  You'd still have to go
and join it manually.  I suspect it's easier for you to just join the groups
via the web interfaces at:

    http://groups.google.com/group/endgame-singularity-dev/

and

    http://groups.google.com/group/endgame-singularity/

There shouldn't be any approval needed, but let me know when you've done it
and I'll go make the necessary tweaks.

I'll do so... but I remember the main list (not the dev one) still being moderated a few days ago
 

> Also, could you please (privately if you want to) give a a little "tutorial"
> on how to manage and properly use the new access? I'm totally unfamiliar
> with administration, since so far I've only worked with that "push to
> private repo & ping the owners" workflow, so an "Admin 101" would be handy :)

I'm actually learning this as I go too; I just started working on another
project using Git where commits actually overlap occasionally (gasp!) and
it's forced me to learn quite a bit more about Git workflow.

I'm learning a TON of git management with my contribuitions to E:S. Nver used so many cherry picks and rebases and merges to "polish" testing/i18n to its final public/i18n form.

As for the workflow, I think in the past 2 months we stablished a quite smooth worflow for E:S, don't you think?
 

Anyhow, feel free to start hanging out in irc.oftc.net #singularity (I just
re-added it to my join list) and we'll muddle through together :)

P

I'm there already, you are AFK... I'll sleep soon (my typing is getting abysmal), but I'll leave IRC on. Eventually we will bump into each other, and it will be a huge pleasure to finally chat with you. This mailing list stuff looks so.. cold :)

ML

PS: i'm still setting up things here, so the commit may take a bit, maybe only tomorrow, hope that is not a big issue to be without Changelog until then. and feef free to post your comments  in the public/welcome commit (but dont merge, please). Also, check TODO, i've added some ideas there...

[Mestre Lion]

Ok, guess I'm good to go...

1st post using my new "persona", and by the looks of github, it all seems fine.

So, what should I do?

ML