[Etoys-notify] [JIRA] Updated: (SQ-131) Translate argument type names

[jira at immuexa.com]

     [ http://tracker.immuexa.com/browse/SQ-131?page=all ]

timothy updated SQ-131:
-----------------------

    Fix Version: M4: production & language (aug)
                     (was: M2: second alpha (june))

> Translate argument type names
> -----------------------------
>
>          Key: SQ-131
>          URL: http://tracker.immuexa.com/browse/SQ-131
>      Project: squeakland
>         Type: Improvement
>   Components: etoys
>     Reporter: team
>     Priority: Eventual
>      Fix For: M4: production & language (aug)

>
>
> From TRAC  Ticket #8696 (bert, sept 2008)
> as reported at http://lists.laptop.org/pipermail/etoys/2008-September/002643.html
> (scott) Fileout playerParmFixes-sw.9.cs.gz, attached to TRAC ticket 8694, purport to fix this.
> (bert) It's translated all right, but CamelCase is back which we wanted to get rid of. Also your new noCamelCase property actually preserves CamelCase symbols.
> Hmm, I think I'd rather not introduce the noCamelCase option in the first place. Why would we *not* want to un-camelcase?
> (scott) IMO "Getting rid of CamelCase" was done in too all-encompassing a fashion. For 'types', because the type name has always been used as the "variable name" for a method parameter of that type, it makes sense for the name used to be a valid identifier, so spaces are inappropriate, and additionally the gratuitous introduction of un-camel-casing to types resulted in the inconsistencies of capitalization between the various places one sees type-names, as was complained about in the original bug report.
> Similarly, another unfortunate concomitant of the over-aggressive un-camel-casing campaign is that user-defined instance-variables show up with un-camel-cased names in the Viewer -- but they appear in their original run-on, non-came-cased version in Scriptors, and of course in the actual code when the actual code is viewed textually.
> So to my mind there are very good reasons for rejecting un-camel-casing in the cases of types and of user-defined variables.
> (bert) Well, you are right about the inconsistencies. Those should be fixed. User-defined strings (var names, script names etc.) should never be touched (I remember seeing user script names being translated which is plain wrong).
> But, since we want to allow translation for all the types anyway, what's keeping us from at the same time get rid of the camel case? In many translations there would not be upper/lower case anyway.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://tracker.immuexa.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira