Don't enforce 'inline' as the default format if none is specified.
Instead preserve the unspecified value as 'null'. This allows
third-party tools to provide a better default experience when changing
existing content (e.g. by using smart detection to follow the format
already used).
Bug: T128337
Change-Id: I911c7999e3731c0125fc058118f8d7287d8f88f4
Not having two lists of all the parameters seems like a good idea.
Depends-On: I30d1f7f56230d73eb47ccbf9881c0b952b15bd89
Change-Id: I5b2ba39fb7b98fc50816f63bc4fbfc9fe25e02a5
Depends on Ieaf19fe4485b679e0ee21d16f8f2e0693808f386 to take effect with the
escape key. Otherwise only handles the visible 'Cancel' button.
Bug: T106382
Change-Id: Ibc55727fd6a5becfe10b4e74cae5e573d110575d
Adding format data, which defines the preferred source format
to use when using templates.
Possible formats:
* Inline - all parameters in a single line
* Block - each parameter is in its own line
Bug: T64147
Change-Id: Id856c4a38890526060d0619432f06174d66f7792
The message allows per-wiki configuration. The default target is better
for normal users of TemplateData than the previous hard-coded one and
has already been translated in some languages from when it was used
previously.
This also moves the messages dependencies from `ext.templateData` to
`ext.templateDataGenerator.ui`, which is the only module that uses
them: the correct strings were displayed only by inheritance.
Bug: T112011
Change-Id: I81ab684bb0ed9b0767df75635284c51129ac7000
Add a sourceHandler that deals with all source-related actions
like fetching template source and validating the existing
TemplateData string.
Also add a MessageDialog warning the user in case the TemplateData
is invalid. In this case, the user will be given the option either
to correct the JSON by hand or to start the editor to replace the
existing TemplateData with a new one.
Bug: T91730
Bug: T91325
Change-Id: I4e6d04f02565a02d8dcf5c70a575ab6433caa27f
