Re: [sahana-maindev] Updating the core language using Pootle

[Gavin T. <gt...@ke...>]

OK, with that information on the table, what would you save if I  
started making wholesale changes to the text in the code and  
potentially updating quite a few strings in Sahana? I'm seriously  
thinking about dedicating some serious time to work on the code itself  
to affect the change.

My original suggestion was as a means to not rock the boat ;)

What I probably need is a reminder from Pottle every week that there  
are x untranslated strings in projects I manage - that would be a good  
reminder to return more frequently :)

Cheers Gav


On 2009-01-27, at 2007, Dominic König wrote:

> Hello Gavin,
>
> let me comment this from a non-technical management view:
>
> Shit happens...occasional changes in the text base of a software are  
> normal
> and legitimate,and the translation teams should be able to keep their
> translations up-to-date with a delay of max. 3-7 days. In my  
> opinion, the
> strings should not get locked at all, developers and maintainers  
> should be
> free to update the text base at any time and for any reason (e.g.,  
> bugfixes).
>
> The modified strings then get merged into the PO template and the  
> translation
> projects (at the Pootle site) will be updated as well.
>
> 80 to 90% of the text base would be more or less stable, while only  
> the rest
> would be subject to occasional changes. So the goal for a pre-release
> translation is 80 to 90% and this is the threshold when I call a
> translation "complete". The remaining strings can be done at any  
> time the
> release gets finalized for issuance - with the proposed maximum  
> delay of 3-7
> days.
>
> But to be realistic - Sahana translation _should_ be dynamic, but up  
> to now,
> this is wishful thinking. Most of the translators act just one time  
> and then
> turn over to other tasks. This seems to be a natural difference  
> between
> software development and language translation.
>
> So, the key feature to get this resolved is to have communities of  
> translators
> that provide something like a continuous attendance to the project.  
> And this
> is what needs to be solved rather (by me :-S I fear).
>
> Dominic
>
> tisdag, 27. januari 2009 01:02 skrev Gavin Treadgold:
>> OK - I'm now about 38% of the way through the en_uk translation and
>> hope to finish this later this week. Getting back to the bigger issue
>> of how do we manage translation on a release by release basis, I'd
>> like to suggest the following based on what I've heard to date, and
>> get some feedback.
>>
>> Apologies if all this happens already and I'm just not aware of it ;)
>>
>> 1. I think we may need to introduce (if we don't use already) a
>> feature freeze at a certain point in advance of a release. Up until
>> this point, strings can be modified directly in the code (through the
>> patching process).
>>
>> 2. At the feature freeze, the strings are locked and then exported  
>> for
>> translation to other languages.
>>
>> 3. After the release, the strings for the stable branch are still
>> locked - but open for translation into more languages.
>>
>> 4. After the release, the trunk is again opened for editing strings  
>> in
>> advance of freeze that kicks off the next translation sprint before
>> release. Of course if the trunk remains open for editing strings all
>> the time, that suits me fine - just as long as the release branch (3)
>> is locked.
>>
>> I'm prepared to stick my hand up to grab source at the next suitable
>> window and start directly editing strings - from what I've seen in
>> translating en_uk, there is quite a bit of work to be done. Of course
>> I'll need help getting started with downloading from CVS and creating
>> diffs for patches. I just want the OK for when is a good time to do
>> this - clearly editing strings in the code soon before a major  
>> release
>> is a Bad Thing :)
>>
>> Is this the sort of process that would tie string editing to the
>> release process in a workable manner?
>>
>> Cheers Gav
>>
>> On 2009-01-21, at 2028, Fran Boon wrote:
>>> Dominic König wrote:
>>>> One good example (don't know where this thread is now) - the  
>>>> "State/
>>>> Status"
>>>> problem:
>>>
>>> Fixed in both Stable & Trunk.
>>>
>>>> I suggested to
>>>> post suggestions for base text corrections to a "correction
>>>> wishlist" which
>>>> can be backpropagated to the developers (that way the State/Status
>>>> has been
>>>> solved in the meantime). But I did not yet find a good place for
>>>> the "correction wishlist" (Wiki? L10N Group? Bugtracker?).
>>>
>>> The current procedure to suggest code changes is the
>>> Bugtracker...ideally with a patch.
>>> It would be good if the L10N group had reached consensus 1st using
>>> whetever tools they wished for that task.
>>>
>>> F
>>
>> ---------------------------------------------------------------------------
>> --- This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Sahana-maindev mailing list
>> Sah...@li...
>> https://lists.sourceforge.net/lists/listinfo/sahana-maindev
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword_______________________________________________
> Sahana-maindev mailing list
> Sah...@li...
> https://lists.sourceforge.net/lists/listinfo/sahana-maindev