Philippe Bossut wrote: > I'd like Chandler to allow the use of a translation egg for English > (yes, American English aka en-US). The string in the code would be the > default "geek speak English", usable but could differ from the final > reference. The proper English strings would be delivered via the message > factory.
I am not sure I understand fully what you propose. Do you mean we would extract all strings from Chandler and create an exact duplicate of the strings in en_US locale egg? Or do you propose we change Chandler code to use some other kinds of identifiers so that some locale egg is required to see any text in the UI? > - Issue1: Minute changes in strings in the code end up breaking all > localized eggs > e.g. Changing "Today" in "Today's events" last week broke my French > translation and since "Aujourd'hui" is already longish, I'm not planning > to change this to anything else. It's a minor pain today but imagine > breaking 87 localized languages with a last minute change like that... > painful... I don't see how having an egg for en_US would help. What would help, and is actually my preference, is that once we start getting serious about trying to ship multiple language versions of Chandler simultaneously we add an Internationalization/Localization Freeze to the process. This would be a signal to developers to stop making any changes that affect localization, and signal localizers that it would be pretty safe to start working on the localization without fear of strings changing underneath before the release. This is how Mozilla does things. However, since we are nowhere near the stage (AFAIK) where we want to ship simultaneous language versions I think even this whole discussion is almost moot at this point. I would say that localizers who do not want strings to change under them should start the localization work AFTER we have made the release. Given that it is only going to take a day or so to do a localization from scratch this could still mean many localized versions available in a very short period of time after a release. > - Issue2: Some strings are identical in English but different in other > languages. > e.g. "to" in the DV is used twice but would actually need 2 different > strings in French because of the different contexts. Allowing the code > to add context and have "to(in)" for interval time and "to(date)" for > final date would allow me to have "au" and "jusqu'au" separately. Bryan > Stearns shown me another way of doing this though I just can't remember > what the trick was. > (Note that allowing dupes in the po and have 2 or more entries for "to" > wouldn't help me much since I would lack the context to understand which > "to" is what...) I think this is an issue even with context in the strings. From my experience translating Mozilla a way back I could not figure out from the strings where they were actually going to be shown in the UI, which is the context that really matters. I had to translate, run the app, and correct places where I had chosen a wrong term. Note that Mozilla requires a 'localization' even for en_US because all strings are specified using ids which are then looked up from the localization files when the app is running. > Beyond not breaking localized eggs, this will allow easy fix of typos > and allow non devs to polish the UI wording without interfering with the > work of localizers. I grant that this would be a benefit, but I don't see this a big problem. > One *very* nice side effect for localizers and PPD alike is that changes > to the "Welcome" message will be possible till the last minute without > impossible to achieve synchronization between people scattered around > the planet. Actually, we could (should) even suppress this lengthy > message entirely from the .py, replace it in there by _(u"Here goes the > long welcome message") and have this message live only in the en-US po, > making possible for Pieter and al, to fiddle with it till the last darn > second without interfering with the main svn tree. I'd say this to be something that must be completed before i18n/l10n freeze if we go that route. Now I just say: if this is a concern, wait until after the release to translate this. I am a little surprised by you making it sound like a big problem that your translation broke. Do the tools allow you to easily translate the changed parts, or do you have to start over from scratch? I sincerely hope the former, which was also the case with Mozilla (Mozilla even needed custom localization tools developed). -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design
