This is a fun conversation, but I'd like to hear other voices. Let me try to rephrase the core positions and present a possible compromise, to make it easier for others to weigh in on which they support. Please correct me where I've misread you.
<br><br>1. MAP position: Better to do the whole job<br><br>If we&#39;re going to be translating, we should translate everything. On-disk identifiers should ALL be either tagged with a language, or in English. Being universal helps keep things clean. When importing a file, you import its dictionary, and the dictionaries of all the files it imports (with intelligent resolution of conflicts). When creating a new English translation for an untranslated identifier, the editor ??automatically applies it in all files with that identifier??.
<br><br>1a. The translation logic knows enough python grammar to display fake import statements.<br>1b. A non-English user will find editing their own files without the &quot;intelligent&quot; tools pretty annoying, as nearly everything will have language tags hanging off of it.
<br><br>2. JAQ position: Better to do a good half job<br><br>Translating everything is an impossible task, we should try to encourage focusing translation efforts where they are most natural, produce the most benefits, and get the most attention (thus quality); this means means on the interfaces between modules. On-disk identifiers should be either (assumed) in a file&#39;s preferred language, in English, or tagged as untranslated imports from a different-language file. When importing a file, you import its dictionary but not those of all the files it imports (except, as a special case, method names and method-call variables of its explicit superclasses). When creating an new English translation for an untranslated identifier, the editor (tries to figure out what imported files to apply it to, but) requires user guidance to apply that translation to 1 file only.
<br><br>2a. The only python that the translation logic knows is how to read &quot;import&quot; statements. Everything else is display-only and it never changes the syntax, just the lexes.<br>2b. Editing with a dumb editor is possible (assuming alphabet issues can be resolved). This is somewhat more dangerous in terms of introducing rare bugs, if there are incompletely-translated files imported in different languages, but it is a viable option.
<br><br>3. Compromise: Do a good half job first, then optionally do the whole job.<br><br>When initially created, files have a &quot;preferred&quot; language and things behave more-or-less as in 2. When somebody decides that the &quot;interface&quot; for a file has a complete English translation, they can convert that file into &quot;English preferred&quot;, which puts language tags on all identifiers not yet translated. This also creates an &quot;internal&quot; section in that file&#39;s translation dictionary which is not used by clients (until the user asks for it, and it&#39;s then moved to the &quot;public&quot; section of the dictionary). An English-preferred file can be edited in another language, and all new identifiers are tagged with the UI language. Thus, English-preferred files behave much as in option 1.
<br><br>3a. a choice between 1a and 2a, I don&#39;t see a compromise.<br>3b. This leads to a natural compromise here.<br><br>Those are simplified positions, there&#39;s a lot of tricky details unsaid on either side, but I hope I&#39;ve at least given them good taglines.
<br><br>As for the details of your message:<br><br><div><span class="gmail_quote">On 8/14/07, <b class="gmail_sendername">Marc-Antoine Parent</b> &lt;<a href="mailto:maparent@gmail.com">maparent@gmail.com</a>&gt; wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>&gt; 2. It also means that the dictionary for a given module could get<br>&gt; filled up with translations of each functions internal variables, etc.
<br><br>I see that as a desired feature. Code is always its own best<br>documentation; reading code from experienced coders is the best<br>learning strategy. So being able to display globally translated code<br>feels necessary to me.
</blockquote><div><br>See above. I think this is our main philosophical disagreement; I&#39;d rather not pollute the translation map with imported unreliable internal translations, sooner or later synonyms will bite you.</div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>One thing I wonder about, from some of your remarks: If module X<br>imports module Y, do you expect translations of Y identifiers (and
<br>the name &#39;Y&#39; itself) to be found in the X translation file? I reread<br>you and it seems not, but I&#39;d like to make absolutely sure.</blockquote><div><br>No. DRY, SPOT, and all that. Doing this wrong was the hairiest of the beasts in my first, abortive, attempt to do this.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Related question: Do you expect translation to carry between modules?</blockquote>
<div><br>Yes, I expect it to carry across one level of importation. Not across any module in the universe, oh God no.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Eg would translating file.close as fichier.fermer have an impact on<br>anything named &#39;close&#39; in any module (such as StringIO)?<br>I admit I did not think so initially: translations were module-<br>specific in my mind. But I am now reconsidering; my initial position
<br>certainly makes duck typing un-intelligible. But applying<br>translations broadly may be an issue in some cases, and introduce<br>more ambiguity. </blockquote><div><br>Again, this is the reason I want to start out NOT translating module internals - overapplying half-assed internal translations.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I will think more about this, and I am curious about<br>your thoughts. (I am mostly curious to see if this is how you saw
<br>things.)<br><br>&gt; If you have a good solution for the problems I mention above, I&#39;d<br>&gt; be happy to consider it. As it is, I&#39;m not saying it&#39;s impossible,<br>&gt; but my feeling as I tried to code it initially was that if you try
<br>&gt; to make things too &quot;magic&quot;, eventually you&#39;re going to make the<br>&gt; wrong assumption and you&#39;re going to create some bugs in the code<br>&gt; being edited that are really really hard to track down.
<br><br>I do not believe I introduce so much magic; so I am wondering whether<br>there is a misunderstanding in some key assumptions that make what<br>you attempted very different from what I am trying to explain.<br>But then, I must admit I did not try coding either!
</blockquote><div><br>I think I understand you better, and no, I don&#39;t think your idea would be so impossible to implement. It would lead to very crowded translation dicts though, and that is IMO a bad thing (synonyms and just poor-quality translations would both bite you). 
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>&gt;&nbsp;&nbsp;And what is the benefit? Modules which are a &quot;language soup&quot;,
<br>&gt; maintained by an international coalition of children who can&#39;t even<br>&gt; talk to one another.<br>&gt;<br>&gt; I support the idea of international, cross-language programming<br>&gt; collaboration. However, I think that a basic assumption would be
<br>&gt; that there were at least one common language of communication<br>&gt; between the participants, and that any given module has an owner<br>&gt; and thus a preferred language for all its still-untranslated<br>&gt; identifiers. If somebody wanted to &quot;add to&quot; that module, they&#39;d
<br>&gt; have to either write in that preferred language or use an explicit<br>&gt; import and subclass (or, of course, just do it in their language<br>&gt; for their own private use, because that file would then be<br>&gt; explicitly marked as &quot;messy and suggested not for sharing&quot;)...
<br><br>You are quite right, this is the crux of the argument: are there real<br>use cases for it?<br><br>First, I agree with you that children who can read nothing about a<br>module cannot use it; for example, we assume that the tool is useful
<br>to non-english speakers insofar as a translation is provided in a<br>language they understand.<br>So we can assume that if people are collaborating on a module, there<br>are common languages. Not necessarily one, however; If I write a
<br>module in French, a Belgian can provide a Flemish translation, that a<br>South&nbsp;&nbsp;African should be able to decipher and edit in Zulu. This does<br>not require me to understand Zulu; and more important it does not<br>require the South African to read French. I think that this would be
<br>a realistic benefit.<br>It does, however, require the Belgian kid to keep busy translating if<br>I am to re-use the code from the Zulu-speaking child! How likely is<br>that, realistically? You may be right, and that process may be one-
<br>way only. Yet again... In my view, it depends on the difficulty or<br>ease of making and distributing translations (which is why I was<br>thinking of distributed databases...)<br>Also, it depends on language community size... Suppose the module is
<br>written in English, and two people maintain a Spanish and a Russian<br>translation independently... it is quite believable for improvements<br>to be made in either language that could not be read by the other<br>community; yet English as the hub makes it likely that they will see
<br>one another&#39;s improvements.<br><br>Let me summarize: my use case for doing this could be stronger; but I<br>would argue it does exist, and for my part I am not yet convinced<br>that identifier-specific language tags present such difficulties as
<br>you suggest. Again, I would like to understand better what problems<br>you ran into (other than those above, which I think I mostly<br>answered, save point 4.)</blockquote><div><br>Nothing to add. I still feel my way. 
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>&gt;&gt; a) I believe there should be one translation file per language.<br>
&gt;&gt; More file pollution, less parsing.<br>&gt;<br>&gt; My current mockup is going to use csv for its dictionary file<br>&gt; format - Engish in the first column and one language per additional<br>&gt; column, in order of addition. Internally it is just a 2d array - a
<br>&gt; list of lists. A &quot;row&quot; is only as long as it has to be and can have<br>&gt; any number of &quot;empty&quot; values as long as at least one value is<br>&gt; defined. The parsing on this file is, needless to say, trivial. It
<br>&gt; would not be much harder if you converted it to XML, with one word<br>&gt; in one language per line, and you&#39;d get more-fine-grained diffs for<br>&gt; free.<br><br>Hmmm... Here, allow me to insist. You are mentioning Garifuna, so I
<br>assume you are interested (as I am) in languages with a comparatively<br>small population base. According to Ethnologue, there are &gt; 6900<br>living languages, of which &gt;1200 are spoken by populations of 100K or<br>
more. Assume only half of that is represented; assume identifiers are<br>16 bytes on average (not generous at all: multibyte in utf-8 often<br>costs double, when not triple!); assume (round number) 50 public<br>identifiers per module; assume 5 modules are imported, we&#39;re well
<br>over 2 Mb worth of parsing... I honestly think this is worth avoiding.</blockquote><div><br>Even if we don&#39;t have a scifi&nbsp; live, wiki-style central translation database, I think we can at least count on some sort of managed git type deal. It would not be very hard to make a tool to merge in or delete out languages from a given translation file, as long as there was at least one canonical language for each file. So on my computer, I only have the languages for my country, including immigrant communities weighted by some compromise between the total language size and its in-country size, plus English. 
<br><br>And even a pretty fragmented country, like Guatemala or Mexico, doesn&#39;t have more than a few dozen languages, of which at most a handful are over your cutoff of 100K. (Here, there are officially 25 languages, of which I think about 5 beat 100K). I think that translation burden and quality concerns become pretty unmanageable below some number in 50-100K. So: say I have 12 languages in my versions of the files (generous, I think) Say that each identifier has an average of 10 versions. With your factor of 50*16*5 that gives 40K of (easy) parsing (and memory use)... a noticeable, but not an unmanageable, number. Still, you&#39;re right, indiscriminate importation (which is a phase some new programmers go through) could bring the OLPC to its knees as you opened Develop. 
<br><br>But I&#39;m actually saving on &quot;disk&quot; (NAND or whatever you call it) space versus your proposal, because I&#39;m giving the same languages (I assume) without repeating the English in every file.</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>&gt; I have found one case where you actually need to do a manual<br>&gt; disambig for every case of an identifier in your file. Say you are<br>&gt; importing an English color_module with the translation red -&gt; rojo.
<br>&gt; You&#39;re also importing an UNTRANSLATED spanish_networking_module<br>&gt; which uses the identifier red. Now you want to add the translation<br>&gt; network -&gt; red to spanish_networking_module. If you were working in
<br>&gt; Spanish, the editor could have warned you when you typed &quot;red&quot; and<br>&gt; helped you change it into &quot;es___untranslated___red&quot;<br>&gt;<br>One possibility I thought about, which may help a bit: start with
<br>that. I.e. the intelligent editor (at least, though I realize we<br>cannot rely on it) would write es___untranslated___red in the .py<br>file in the first place.</blockquote><div><br>Which .py?&nbsp; my_network_colors or spanish_networking_module? If you mean the latter, yes, this is a good idea that I hadn&#39;t thought of, but it also introduces bloat and makes a dumb-editor harder to use for the file&#39;s author.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That means less ambiguity in the actual .py file, esp. if it is used<br>later in a non-language aware editor.
</blockquote><div><br>less ambiguity in my_network_colors, right?<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That said, the user will only see rojo and (spanish) red, right?
</blockquote><div><br>if my_network_colors is in Spanish. But if it&#39;s in English, they&#39;ll see red (colored english), unless the editor has some reason to know that red has been imported from spanish_networking_module.py. Hopefully, if they ever mean the spanish one, they&#39;ll notice it&#39;s colored English, and say &quot;no I mean the one from s_n_m&quot; at which point it will turn to es_untranslated_red and red will be added (without translation) to the spanish column of the dictionary for s_n_m. Adding the translation later will be no problem.
<br></div><br><br><div>Cheers,<br>Jameson<br></div></div><br>ps...<br><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>so-called &quot;arabic&quot; numerals (westernized<br>indic!) </blockquote><br>
&nbsp;Indic? That&#39;s a new one on me!<br>