View source for Thread:Support/About Blockly:TEXT JOIN HELPURL/ko/reply
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in the group: Users.
You can view and copy the source of this page.Siebrand
Needs proper plural support. Not all languages only have singular and plural.
There's jQuery.i18n at https://github.com/Wikimedia/jquery.i18n which has it. You could use the parsers and the format, or adopt the framework.
Documentation and message text do not relate to each other.
This message must be fuzzyed except English, Korean, Japanese, Malay, Ukrainian, and qqq.
"Error parsing XML: (error msg) Abandon changes?"
According to the documentation, the user gets the buttons "OK" and "Cancel" to choose from. This is unclear and incorrect, as choosing "OK" would actually cancel the changes, and choosing "Cancel" would keep the changes and return the user to the editor to fix it manually (which is the opposite of cancelling).
At minimum, the buttons presented should be "Yes" and "No". Much better still would be "Abandon" and "Keep".
This is an excellent point, which I will bring up with my tech lead.
I spoke to my tech lead, and he said:
- You're right.
- The reason we have OK/Cancel is we're using the default dialog window.
- This message is not frequently seen.
For now, I will rephrase the English-language message to make it clearer what the user should do. It may take a few days for the change to show up in translatewiki.
As documentation: this should only be changed by Blockly developers, not translators.
"Pegman" should be "(The) player" for consistency with other messages.
- ("Breaking a problem into two pieces can make things easier.")
Duplicate spaces (after full stops) in source messages:
- ("Could not load your saved file. Perhaps it was created with a different version of Blockly?")
- ("A program is a sequence of blocks. Stack a couple of 'move forward' blocks together to help me reach the goal.")
- ("Computers have limited memory. Reach the end of this path using only two blocks. Use 'repeat' to run a block more than once.")
- ("An 'if' block will do something only if the condition is true. Try turning left if there is a path to the left.")
- ("Can you solve this complicated maze? Try following the left-hand wall. Advanced programmers only!")
Thank you. I grew up in the old days of typewriters. I've made the fix in the source files (although they won't show up on translatewiki immediately).
Actually, before I make this change, could you tell me why you think two spaces is incorrect? We're willing to make a change if that's site policy but not if it is personal preference.
(Sorry for not responding sooner. I only just learned how to see my support messages.)
I'm working on creating message documentation for Blockly. I'm not sure how to describe tooltip messages, as shown in yellow in the picture below. What would be good message documentation for "Return the square root of a number."?
Screenshots can be used, though a lot of work. At least do mention it is a tooltip.
This message should possibly be ignored, at least for time being and if it is true that we have accidental translations. Of course, they may be not accidental at all. :-)
Blockly likely does not have it, but here PLURAL or an equivlent should be used.
How should we translate the word block? Should we translate it as "city blocks"?
These messages should be using something like PLURAL.
I'm an engineer on Blockly, an open source (Apache License 2.0) programming environment aimed at helping children learn to program. Here's a maze tutorial and a write-up of its use in Vietnam by my colleague Neil Fraser. Blockly is hosted at Google Code, where you can see it is under active development. We have some enthusiastic volunteers and have already gotten the maze tutorial translated into 7 languages using ad hoc technology, but we want to do much more, which requires the sort of technology (and access to volunteers) that you offer. We have already begun generating .pot (gettext) file but could create other formats if they're better. We've looked into Transifex, but their limits on the length of message documentation are insufficient, among other things.
That looks like an awesome app. I've seen something like that in a TED talk recently. Can we do a hangout on this somewhere this weekend to see what we can make happen? Please contact me at siebrand AT wikimedia DOT org. I live in the Netherlands, so I'm UTC+1 (until Sunday, when that changes to UTC+2).
Status update for thread followers: Looks like we will be supporting this product within a few weeks.