The new `maybeFormatMessage` function detects whether its argument
looks like a message descriptor object and, if so, will call
`formatMessage` on it. This is now used for all user-visible text fields
in extensions.
Also, messages may use "select" to check the target type with a message
like this: '{targetType, select, stage {text for stage} sprite {text for
sprite} other {text for other}'. Note that the "other" clause is
required by `formatMessage`.
A LOOP block is like a conditional, but the LOOP block will be
re-evaluated after any child branch runs.
Also:
- Support using '---' as a block separator
- Refactor common code from `_registerExtensionPrimitives` and
`_refreshExtensionPrimitives` into new `_fillExtensionCategory`
- Improve error reporting during block conversion
When the extension system calls a function to retrieve extension menu
items, it now provides the ID of the current editing target. There's
also now a little bit of error-checking on the results.
Some reporters are sprite-specific, such as the costume name/number or
X position of the sprite. Others are global. This enum allows an
extension author to specify the scope of a reporter.
* localize the block and menu strings in the pen extension
* adds .tx/config to be able to push translations to transifex
* includes format-message to localize strings and extracting them.
* add setLocale function to VM to allow GUI to pass in locale data.
* refresh block definitions when the locale changes.
### Still to be decided
For now just extracting messages from the pen extension into their own file. We’ll need to decide if each category gets its own file, or group all the strings into one resource.
Since we will only have builtin extensions for a while, the
more-complicated, watchdog-based extension duplication prevention has
been replaced with one that treats the extension URL as equivalent to
the extension ID. This is true only for built-in extensions, so once we
start supporting third-party extensions we will likely need to bring
back the watchdog (commit e4381b4693) and
the more-complex duplication prevention (commit
670e51d335).
The code here should be treated as a last resort: ideally the GUI should
check if a particular extension is loaded (maybe by calling the
Extension Manager's new `isExtensionLoaded` method) and avoid calling
`loadExtensionURL` if it is.
If an extension attempts to register with the same ID as another
extension which has already registered, the new registration is refused.
If the extension is in a worker and no other extension is successfully
registered by that worker, the watchdog system will terminate the
"empty" worker.
If an extension worker does not complete initialization in a reasonable
amount of time (currently 15 seconds) then the worker will be
terminated. A complete initialization includes registering an extension.
WeDo2 and Pen blocks have been converted to internal extensions, and can
now be loaded by giving `loadExtensionURL` the string 'pen' or 'wedo2'
instead of an actual URL.
The new `_registerInternalExtension` method on the extension manager
will register an extension object (an object with a `getInfo()` method)
with the extension system without sandboxing the object in a Worker.
When asked to load an extension, the Extension Manager starts up a new
Worker. That worker runs the message dispatch system as well as an
instance of the new `ExtensionWorker` class, which will load the desired
extension and register it with the extension system.
Extensions, placed in `./src/extensions/*.js`, are now processed by
Webpack as separate entry points and packed into an `extensions`
subdirectory in the output.
Still to do: query an extension's information, including the blocks it
provides, and register that information with the VM, GUI, etc.
