he transparency.
>
> -Mark
>
> -Original Message-
> From: Héctor A [mailto:neverbi...@gmail.com]
> Sent: Wednesday, December 03, 2014 6:07 AM
> To: dev@flex.apache.org
> Subject: Re: International English
>
> Is this a discussion just for members of the Apache
dev@flex.apache.org
Subject: Re: International English
Is this a discussion just for members of the Apache Flex team? if not, I
just wanted to give my opinion as a foreign Flex user... sincerely, I don't
care about UK English, US English or neutral English, excluding for slangs
and/or cultural re
Discussions are for everyone. Don’t hesitate to comment on anything.
Harbs
Is this a discussion just for members of the Apache Flex team? if not, I
just wanted to give my opinion as a foreign Flex user... sincerely, I don't
care about UK English, US English or neutral English, excluding for slangs
and/or cultural references, they all feels mostly the same for me, I'm used
Hi,
> What, in your opinion, would adequately resolve this apparent catch-22?
Well the ideal solution would to have more PMC involvement on release votes,
but I've no good ideas how to encourage PMC members to vote on releases.
Thanks,
Justin
On 11/26/14, 2:57 AM, "Justin Mclean" wrote:
>Hi,
>
>> Nowhere in the bylaws (that I can find) does it say that spelling
>> issues in documentation are release blockers.
>
>!00% correct and I'm against it.
>
>> If someone said they should be, that would be an opinion.
>
>Also correct , but:
>a)
What, in your opinion, would adequately resolve this apparent catch-22?
EdB
On Wed, Nov 26, 2014 at 11:57 AM, Justin Mclean
wrote:
> Hi,
>
>> Nowhere in the bylaws (that I can find) does it say that spelling
>> issues in documentation are release blockers.
>
> !00% correct and I'm against it.
Hi,
> Nowhere in the bylaws (that I can find) does it say that spelling
> issues in documentation are release blockers.
!00% correct and I'm against it.
> If someone said they should be, that would be an opinion.
Also correct , but:
a) With the new no RC process, (which IMO basically require co
On Wed, Nov 26, 2014 at 11:43 AM, Erik de Bruin wrote:
> ...That opinion might translate into
> a -1 vote, but I just checked and that wouldn't amount to a veto for a
> release
I agree that releases cannot be vetoed.
OTOH someone can technically veto a commit that introduces a spelling
error
Justin,
> Most of the SDK (error messages and the like) are localised so there's
> nothing that needs to be done there - other than keep it up to date and add
> new locales where people can contribute. The current area of disagreement is
> actually very small and if the spelling issues in READ
Hi,
Thanks for stepping to to helping out Bertrand, sorry you need to spend time on
this.
> My recommendation would be to find a technical solution to what is a rightful
> community issue
Most of the SDK (error messages and the like) are localised so there's nothing
that needs to be done ther
On Wed, Nov 26, 2014 at 10:30 AM, Erik de Bruin wrote:
> ...can a vote also be (to
> put it bluntly): "[VOTE] stop being pains in the project's buttocks
> and leave the spelling/grammar issue well enough alone!"...
A PMC can make their own rules on such things, but IMO the best way to
end discuss
Personally, I’m more comfortable with broader consistency (in website, etc.),
but I’m fine with this.
Since user facing text is all localized already, based on your suggestions, we
can drop this whole discussion.
Thanks,
Harbs
On Nov 26, 2014, at 11:45 AM, Bertrand Delacretaz
wrote:
> Hi,
>
Hi,
On Wed, Nov 26, 2014 at 10:28 AM, Harbs wrote:
> ...The way I understand your suggestion is like this:
> We agree on variant “X”
I would only care about localizing text that is visible when people
run a Flex application - dialogs, error messages etc.
As for everything else, that's eithe
Very good question.
I see having an agreed upon method of killing discussions as a very positive
move.
On Nov 26, 2014, at 11:30 AM, Erik de Bruin wrote:
> A second question: would it be OK to call a vote to end a discussion?
> In other words: does a vote always have to be about something tang
A second question: would it be OK to call a vote to end a discussion?
In other words: does a vote always have to be about something tangible
- a paragraph in the Wiki, a release, etc. Or can a vote also be (to
put it bluntly): "[VOTE] stop being pains in the project's buttocks
and leave the spellin
Just to use Alex’s division of items in an attempt to make things clear:
1) Release package documents: README, RELEASE_NOTES, LICENSE, NOTICE,
CONTRIBUTING, etc.
2) API names (classes, properties, styles, etc)
3) ASDoc and JavaDoc comments (really, any comments that end up in user
documentation)
4
What is the Apache Way (tm) to 'agree to disagree'? When there are two
opposing positions that are both right, but different enough not to be
able to reach a compromise, what action might break the deadlock?
A vote would result in one side 'losing', something we have been
trying to avoid in this p
Hi,
I read that thread at http://markmail.org/message/qbipsoo3k4umbh4a
IMO that's a typical example where it's impossible to come up with a
"right" solution...people have various levels of concern for that
issue, ranging from exactly zero to "my customers say our stuff is
crap when they see that"
Hi,
> Yes, I have asked the board for advice on how the project can have fewer
> lengthy discussions like this.
Thanks for that. IMO it may of been better to put that in your original email.
Perhaps next time think about involving the PMC and/or perhaps (depending on
content) CCing the emai
not a deliberate change of en_US to international
English. A casual inspection showed no errors / red squiggly lines in my locale
that is all.
Thanks,
Justin
On 11/25/14, 1:07 PM, "Justin Mclean" wrote:
>Hi,
>
>> Alex obviously asked for advice on how to handle this. That’s a
>>perfectly valid thing to do.
>
>Which is fine, but let Alex answer. I think it's a valid question, as
>part of the Apache Way is openness. [1]
Yes, I have asked the board fo
On 11/25/14, 1:34 PM, "Justin Mclean" wrote:
>
>Actually what started this off is that Alex submitted a commit that
>changed something into US English and the previous spelling errors being
>a blocker to releases discussion.
Here is a commit email [1]. Below is the relevant part. It shows you
Hi Justin,
I just responded off list.
Thanks,
Harbs
On Nov 25, 2014, at 11:34 PM, Justin Mclean wrote:
> Hi,
>
>> It’s an antagonistic question
>
> Zero antagonism was meant or even implied. I know email tone can be hard to
> decipher sometimes, but please don't assume ill intent when none
Hi,
> It’s an antagonistic question
Zero antagonism was meant or even implied. I know email tone can be hard to
decipher sometimes, but please don't assume ill intent when none exists. Also
please try to be a little more courteous and respectful on this public email
list.
> He wants to dis
On Nov 25, 2014, at 11:07 PM, Justin Mclean wrote:
> I think it's a valid question
No it’s not. It’s an antagonistic question and has nothing to do with the pros
and cons of the discussion.
Let’s say Alex made that up. Who cares? He wants to discuss how to handle
localization/languages/whatev
Hi,
> Alex obviously asked for advice on how to handle this. That’s a perfectly
> valid thing to do.
Which is fine, but let Alex answer. I think it's a valid question, as part of
the Apache Way is openness. [1]
Thanks,
Justin
1. http://theapacheway.com/openness
Justin,
Please give it a break.
Alex obviously asked for advice on how to handle this. That’s a perfectly valid
thing to do.
On Nov 25, 2014, at 10:18 PM, Justin Mclean wrote:
>> The board member who has been trying to follow the project recommends we
>> put the issue of US vs Int’l English t
Hi,
> So how about adding this:
>
> “Good-faith efforts at modifying text by non-native speakers generally
> should not be vetoed. Instead, native speakers are encouraged to thank
> them and simply make corrections.”
I'm not sure why you are singling out non native speakers here, any effort to
documents will be written in US English
As previously discussed I'd prefer we try to be more inclusive and use
international English.
> Interested community members can post translated copies of READMEs and
> RELEASE_NOTES (but not the others like LICENSE and NOTICE) on our wiki.
For other n
>>- This is a solution looking for a problem; a waste of everyone's time.
>
> Well, it is the board member’s recommendation. I actually hope to use the
> proposal as a way to invite folks to contribute translated versions.
Board members don't make project policy. But that aside, I wasn't
talking
On 11/25/14, 12:37 AM, "Erik de Bruin" wrote:
>My vote would be a -0 right now, strongly leaning towards a veto - on
>principle.
>
>I object on (at least) 3 points:
>
>- This is a solution looking for a problem; a waste of everyone's time.
Well, it is the board member’s recommendation. I actu
Regardless of the rest of the standardization, I think we should still allow
translation of user docs, website, wiki and GUI tool. Meaning not enforcing a
standard, but allowing better support for alternate languages if someone
desires to put forth the effort of translating.
-Mark
Same vote intention than Erik for the same reasons.
Frédéric THOMAS
> From: e...@ixsoftware.nl
> Date: Tue, 25 Nov 2014 09:37:10 +0100
> Subject: Re: [DISCUSS] Localization Proposal (was re: International English)
> To: dev@flex.apache.org
>
> My vote would be a -0 right now
I did not understand Alex’s suggestion as changing the status quo.
The default language is currently US English. UI-facing components are already
localized. That would all stay the same.
The only suggestion would be to make a (reasonable) effort to use neutral words
when possible and possibly o
My vote would be a -0 right now, strongly leaning towards a veto - on principle.
I object on (at least) 3 points:
- This is a solution looking for a problem; a waste of everyone's time.
- Enforced language rules will raise the bar for entry, especially for
non-native speakers. It's hard enough m
I pretty much agree with these suggestions.
#7 is of less importance than #8
#4 is probably more important than #5, but both seem like a lot of effort. I
guess we’d need volunteers who are familiar in the respective languages to lead
the translation and maintain the specific areas. If we have v
The board member who has been trying to follow the project recommends we
put the issue of US vs Int’l English to a vote. Apparently, the HTTP
project did so in the past (and decided on US English). So this is now a
discuss thread leading to a vote.
Personally, I don’t want to just choose one ove
Hi,
> If we get complaints, we should try to find neutral words, but keep in
> mind that the Apache LICENSE itself contains words with “ize” like
> “authorize”. I don’t see how you’ll be able to remove all US English from
> our release packages.
>
> I would need to see a clear picture on how cha
On 11/23/14, 12:24 AM, "Justin Mclean" wrote:
>Hi,
>
>It boils down to this: About 60-70% of our users understand International
>English, only minor changes are required to accommodate that and be more
>inclusive, why wouldn't we do that?
If we get complaints,
Please don’t quote a partial statement. I explained why I thought it will lead
to inconsistency.
I’m done with this discussion until more people weigh in.
Thanks,
Harbs
On Nov 23, 2014, at 11:33 AM, Justin Mclean wrote:
>> But I DO care that whatever it is, it should be consistent.
>
> And I
Hi,
> First of all, we have no data on what percentage of users prefer US English
> relative to International English.
Yes we do see installer download stats in google analytics it give a reasonably
good indication, especially as the sample set is large. You can even get a good
approxi
o data on what percentage of users prefer US English
> relative to International English. Statistics on where users come for are
> somewhat of an indication, but only a partial indication. How many people
> come from countries where the primary language is English? If English is a
> seco
Hi Justin,
First of all, we have no data on what percentage of users prefer US English
relative to International English. Statistics on where users come for are
somewhat of an indication, but only a partial indication. How many people come
from countries where the primary language is English
Hi,
It boils down to this: About 60-70% of our users understand International
English, only minor changes are required to accommodate that and be more
inclusive, why wouldn't we do that? Or are you saying that data is incorrect?
Granted most of the users don't care one way or a
International English, I find it very hard to swallow that we should invest the
energy in doing so without some concrete evidence that there’s a need.
The two JIRAs you mentioned were issues related to UI. I fully agree that UI
should be fully localized — but that already is!
Can you please provide some
Hi,
> If you agree that we should use backgroundColor, color, and ColorPicker,
> doesn’t that count as US English?
They are names of classes / attributes / styles , we're not going to change
that because of backward compatibility. Names of things can be spelt in any way
and you retain that spel
Hi,
> Proof or it didn't happen.
In one case we had a client refuse to release Flex Application because of the
word "initilizing' in the loading bar (this issue was in an early version of
Flex and has fixed in a later version of Flex). The client was a large
newspaper in Australia and knew the
I don't have an opinion on this general topic one way or another (I prefer
using British English spelling, but I was raised on American English)
However regarding class names... Class names are class names. If Adobe
for the past 10-15 years had a class named BakgroundColorz, BakgroundImagez
and
>>> Before we go off spending energy rewriting the doc, I would like to see
>>> evidence that folks are finding it confusing and that some change is
>>>going
>>> to make a difference. I don’t recall very many JIRA issues about
>>> confusing documentation or threads on the mailing list.
>>
>>Over t
On 11/21/14, 11:53 PM, "Justin Mclean" wrote:
>Hi,
>
>> IMO, we should not be trying to decide between US and Int’l English.
>
>And nor should we be using US English for an international audience given
>who are the majority of our users.
If you agree that we should use backgroundColor, color,
Hi,
> IMO, we should not be trying to decide between US and Int’l English.
And nor should we be using US English for an international audience given who
are the majority of our users.
> For example, I don’t know if our documentation actually contains the
> phrase “your email address is missing
This feels to me like a “solution looking for a problem”. As programmers, I’m
sure we’re all familiar with that phenomenon. ;-)
Until there’s some real evidence that languages and locals, etc. is a problem,
I’m really hesitant to go that route. But if others want to knock themselves
out, have a
entence. In the US you would just
>call it a period (your cycles comment lol). So yes you would have to
>correct me all the time if we went to international English for lots of
>simple things.
>
>Glad we ruled out slang too, because some places here we call exclamation
>marks
ct me all the time if
we went to international English for lots of simple things.
Glad we ruled out slang too, because some places here we call exclamation marks
"bang" signs.
-Mark
-Original Message-
From: Harbs [mailto:harbs.li...@gmail.com]
Sent: Tuesday, November 18, 2
I live in Israel and have plenty of friends from the UK and Europe. I have
plenty of exposure to International English and I’m aware of the differences.
Yes. There are some differences in expressions, but I still think there’s no
one who would think email has menstrual cycles… ;-)
On Nov 18
HI,
> So do we have an English to English translation guide :P ?
I'm sure we could build one but probably no need. There's enough people on this
list who can help out. I would guess there's more active committers who are
based outside of the US than in it.
Thanks,
Justin
So do we have an English to English translation guide :P ?
-Mark
-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com]
Sent: Tuesday, November 18, 2014 7:59 AM
To: dev@flex.apache.org
Subject: Re: International English
Hi,
> I think it should be consist
ted in the release
notes).
> I don’t believe anyone has trouble “translating” between US and International
> English
You'll be surprised, a lot of US expressions and words are virtually unknown
outside of the US and can be confusing eg "You email address is missing a
period&qu
Hi,
> Just out of curiosity are we talking just the slang used or the spelling of
> words?
We should try to avoid slang as it will always be misunderstood by some users.
It's more about spelling, not using US words (eg period vs full stop) and
grammar.
Thanks,
Justin
Just out of curiosity are we talking just the slang used or the spelling of
words?
-Mark
I think it should be consistent. Currently it’s all in US English and the
benefit of changing that is questionable while the effort is huge.
I don’t believe anyone has trouble “translating” between US and International
English, but using one in one place and the other in other places is sloppy
with International lEnglish I have some suggestions:
- For now let make both US and British/International English acceptable. Just
try to be consistent when making a release. [1]
- No need to go and retrofit this change to all existing content, just bare in
mind when updating.
- Normal CTR rules appl
63 matches
Mail list logo
