This is something that's been on my mind a lot recently.

We can't come up with a way to support non-English official communication channels for the Foundation as Bertrand mentions, but if we don't allow non-official channels in other languages, as the saying goes, "the Internet will route around us" and just create them outside of the ASF.

I, for one, would rather see those discussions happening on ASF lists if at all possible. Maybe we can't have a dev-chinese@project.a.o, but couldn't we at least support a users-chinese@project.a.o?

I think it's equally important to consider the i18n and l10n of the software projects that we shepherd. This is something I want to ask the assembled minds in the board/officers at the face-to-face meeting this week.

I know there are some woefully under-recognized solutions within the ASF (such as our Pootle instance, https://translate.apache.org/). Look how few projects even try to use it. This is tragic. And doing what we can to improve things here I feel does fall under D&I. It even meshes with the US non-profit mission of software for/in the public good, since the US does not have an official national language, and has a large percentage of citizens and residents who speak other languages.

On the intake side, we should consider translation of the FAQ and other documents into a few languages, with reverse translations back to English to ensure nuance is not lost (especially for critical documents like the CoC, general project bylaws, and maybe some of "The Apache Way" stuff.) These documents can clearly be marked as "not official" so as to not overburden our thin legal resources to date.

-Joan

On 2019-05-14 12:03 p.m., Alex Harui wrote:
It has been interesting to me how important words are in these discussions.  In this case, the word "fix".  
We may not be able to "fix" as in "eliminate" the requirement to communicate in English, but I 
believe we can and should encourage communities to choose their words more carefully so that "fluency" is not 
perceived as a requirement.  I already do filter my choice of words to try to avoid word patterns that non-US citizens 
may not understand since all but one of the most active committers on my project live outside the US.

We might come up with other social suggestions like allowing posts in other 
languages on users@ lists, allowing posts in other languages on dev@ but 
recommending translation of the original post to English and requiring posts in 
English on private@.  That's sort of how Flex and Royale operate today without 
any official documentation of this approach.

My observation is that restaurant workers in the US in popular tourist areas 
are generally trained to be patient with non-English-speaking customers and 
also choose their words carefully.  Why shouldn't we all take that approach at 
Apache?   Another observation is that airline pilots fly to the US from all 
over the world and communicate in English to flight controllers in the US (and 
other countries too, iIRC).   I'm fairly certain the US-based flight 
controllers choose their words carefully.  I do not think all of those pilots 
from other countries are fluent in English.  They have learned enough 
functional English to communicate on how to navigate and land an airplane.  
Does/should software development at the ASF require an even larger English 
vocabulary than navigating air-space?

My 2 cents,
-Alex

On 5/14/19, 6:27 AM, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote:

     On Tue, May 14, 2019 at 3:09 PM Daniel Gruno <humbed...@apache.org> wrote:
     > ...It's like democracy - while not perfect, it is (I would say) the least
     > sucky way of ensuring fairness, openness and proper governance, as it is
     > the most universal (and de facto standard) language we have..
+1 > I do not see the need for or lack of English skills as a thing *we* can fix... Same here, I was mentioning as one invariant that does affect who
     joins our communities - or more precisely the way people contribute.
-Bertrand ---------------------------------------------------------------------
     To unsubscribe, e-mail: diversity-unsubscr...@apache.org
     For additional commands, e-mail: diversity-h...@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: diversity-unsubscr...@apache.org
For additional commands, e-mail: diversity-h...@apache.org

Reply via email to