flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: Working groups - different approach
Date Mon, 13 Feb 2012 08:40:17 GMT
The code in the SVN is already translated using resource bundles. [1]

"a professional 3rd party vendor" ? That sounds very strange to me.

But back to the original topic: There should be mailing lists and 
working-group mentors assigned to such working group.
That is at least my opinion.


[1] Example 

On 13/02/2012 13:34, David Francis Buhler wrote:
> Regarding 1&  2:
> Here's one possible way (with ANT) to begin creating localized content
> for the SDK.:
> We copy a RAW SDK into locale-specific folder names during a build.
> We add @Tokens@ in the .as / .mxml (?) files that correspond to help
> content (stored in properties' files)
> We use English as the master locale (all localization is done with a
> Master Locale)
> We use Google's translation service to manage the localization of the
> properties files by volunteers (note: I've never used this service and
> cannot speak to it specifically). With a small financial backing, a
> professional 3rd party vendor could translate the documentation, at
> least for major locales.
> Using AS Docs, we could generate locale-specific help for the SDKs
> during each build.
> [1] http://support.google.com/translate/toolkit/?hl=en
> On Sun, Feb 12, 2012 at 1:58 AM, Martin Heidegger<mh@leichtgewicht.at>  wrote:
>> Hello List,
>> I know we discussed working groups before. This time I want to focus on a
>> different aspect.
>> One person can not know or do everything. Flex has a variety of task in
>> front of it -
>> tasks that are better not ignored - that require a lot of expertise (man
>> power) and coordination.
>> I think of:
>>   *) Translation: Right now the asdoc is translated in many languages. Will
>> we drop the translation? How to keep that up?
>>   *) Testing&  Building: Boring, exhausting, peticular - many programmers are
>> not laid out for it and it will be a lot of work, specially if we change the
>> code rapidly.
>>   *) Documentation: Writing solid code is a entirely different ability from
>> writing/recording good understandable documentation&  examples.
>>   *) Presentation: Logos, Homepage design, Skins, UX, creativity in general
>> ... not the strong suit for many programmers
>> I think it would help the process if there were mailing-lists and persons
>> who can answer in this topics
>> clearly&  have authority: managed working groups.
>> yours
>> Martin.

View raw message