I don't think these should be unified, they look the same, but are different concepts.

For example a translator can define as many local variables as they want.
But they MUST NOT define inputs, as inputs correspond to something in the calling code.

Similar to programming languages:

function foo(String arg1, int arg2 = 42) { // input
   int bar = 7 // local
   int baz = arg2 // local
   String locStr = arg1 // local

TLDR: not unify, they look superficially the same, but are different concepts.

Responding to @echeran:

I like the attempt at simplifying the spec, but it currently doesn't seem to me to an improvement b/c it undoes an important distinction.

With this change, the .input and .local declarations are still distinct and distinguishable from each other in the data model, as the sets of valid "input" and "local" object contents are exclusive of each other. This means that we're removing a current duplication of data.

Responding to @mihnita:

I don't think these should be unified, they look the same, but are different concepts.

For example a translator can define as many local variables as they want. But they MUST NOT define inputs, as inputs correspond to something in the calling code.

As discussed during the 2024-07-15 call, there are situations in which it may be valid for a translator (or their tooling) to add a .input declaration where one did not exist previously.

I can provide a real-world example with this Firefox message, which in MF2 is effectively

{$num :integer} (default)

in the source locale (en-US), but its Japanese translation depends on the OS, requiring the use of a custom :platform selector:

.input {$num :integer}
.match {:platform}
macos {{{$num} (デフォルト)}}
* {{{$num} (既定)}}

Note how the introduction of the .input declaration has not changed the requirements or restrictions on the num value, as in both the source and target locales it's formatted the same way using :integer.

MF2 allows for this, while also allowing for a specific user to choose to restrict changes such as the above. It's also good to note that similar restrictions on the input may also be imposed by a .local declaration:

.local $foo = {$num :integer}
.match {:platform}
macos {{{$foo} (デフォルト)}}
* {{{$foo} (既定)}}

As in the example above using .input, this message requires the num value to be usable as an integer.

In other words, the more appropriate "MUST NOT" to impose on translators (e.g. via tooling) is changes to expressions where the operand is externally provided. Say, if the original was instead

{$num} (default)

then it would not be valid to change the expression to {$num :number} in any locale based on a presumption about the value's type from its name.

That is a restriction which applies to all .input declarations, but it also applies to many .local declarations and placeholders as well; we really should not have .input be special in the data model, as it could mislead other developers the same way about what sorts of changes and transforms could be safe, and which are not.

Discussed in 2024-09-10 call. Moving to post-46 but pre-2.0

This change was rejected in the 2024-10-14 call.