On 16/07/2008, Rotem Liss <rotemliss(a)gmail.com> wrote:
I'd like to toss in some of my own opinions. On-topic discussion at the bottom.
I suggest not to remove the spacing in language files
(everywhere). After trying
to rebuild a language file without spaces, I can see it is much harder to read
and maintain.
True.
While some of the localization is done via BetaWiki,
Most of it, we have hundreds of translators.
I and several
other users update their languages using direct SVN changes, which is faster,
and also easier for some users.
You, Raymond, Shinjiman? Looks like Alefzet has disappeared.
Here are few reasons why I think using Betawiki is better:
1) It prevents collaboration.
It is not possible to work without and with Betawiki at the same time,
because we currently can't handle conflicts very well. This may be
alleviated once we can import external changes, but the issue itself
stays. There is no other central place to communicate with other
translators.
2) Nice features.
Those who work in Betawiki have nice features, like better message
format checks, nice statistics [1], all special page aliases in one
place, no need to commit, easy overview of untranslated messages and
those listed as problematic by the checks.
Then there is the message documentation, and those who contribute to
it are helping everybody else using Betawiki.
And what happens when SVN committers get tired of updating the
localisations? What will happen now that Alefzet is gone? Will we find
new translators, or is the localisation doomed to bit rotting?
We do not tell people how they must update translations, but we do
however, suggest and wish they use Betawiki, for the obvious reasons.
I understand those who work with multiple script variants, it is not
easy to do in Betawiki.
I understand you too, and why you feel using SVN is easier. It is a
trade-off. Certain things are harder to do in Betawiki, even if we are
constantly trying to fix those issues. But this comes down into
manpower, and simply the people working with Betawiki have too many
things to do. We are looking for new faces to handle some tasks, to
leave us more time to work on the hard issues.
This change will make these updates harder, and
will discourage users from updating the localization that way.
True, but my opinions on this are mixed.
It will also make
it harder to read the language files or to find problems in them.
True.
About reviewing localization updates: As Nikerabbit said, localization updates
(especially those from BetaWiki) are usually truncated anyway in mails from
mediawiki-cvs, and using diff tools that ignore whitespace changes (e.g. "svn
diff -x -b", or ViewVC) may be used for reviewing localization changes.
Of course those mails could get shorter, if there were less stuff
caused by the whitespace changes, but I don't think that would have
any noticeable help.
However, there is a problem when many messages are
aligned in the same way. The
problem exists in extensions (e.g. CentralAuth, which contains many messages),
whose translations are not divided into groups. I suggest that the extensions
rebuilding script will support dividing messages into groups and make it
possible to avoid huge whitespace changes when a longer message key is added.
Maybe. This is exactly what we are discussing here. I agree that it
doesn't make sense to align those all by the longest one.
I think we have now following alternatives:
1) remove padding
2) do nothing
3) use a constant pad
4) pad by the longest key in definitions, in which case whitespace
only changes when long keys in English are added or removed
4b) same as above, but allow smaller blocks in extension messages
Rotem Liss
Not specifically targeted to you.
--
Niklas Laxström