So, we could use the strict check as the default one, just keeping in mind
it can shows some (rare) false positives, right?
The other question about this is, is it possible to do this check in DL to
show this typos (like the errors generating POT file are shown, for
example)? It would be realy useful to have this check, so translators and
coordinators would be aware of them.
Cheers
2013/4/8 Shaun McCance
> On Mon, 2013-04-08 at 11:30 +0200, Daniel Mustieles García wrote:
> > 2013/4/6 Gabor Kelemen
> >
> >
> > I think these kinds of warnings are useful, until it is not
> > compulsory
> > to fix all of them :).
> >
> > Why not? I'm not sure about it. If Documentation team adds some tags
> > to the original strings, translators should keep those strings. Also,
> > having freedom to add our own tags to translated string may break the
> > building process so fixing those errors should be fixed.
> >
> > I don't know how Mallard documents work, and how translators have to
> > deal with tags (I mean: should we add or remove tags when translating
> > strings? Shouldn't it be done by the Documentation team?) I think
> > translators shouldn't change the format adding or removing tags
> > (althouhg it doesn't break the compilation), but having some comments
> > from docs team would be really useful.
>
> I think there are cases where it's worthwhile for translators to add
> tags, but they're probably the exception. Thinking out loud:
>
> * East Asian languages might want to add Ruby markup. And this will
> actually work correctly in 3.10.
>
> * Some languages might want to use an English word for a technical
> term when there isn't yet an established local word. They might want
> to mark this with .
>
> * The instructions for certain actions on different keyboard layouts
> might involve more or fewer elements than for en-US.
>
> If we really end up getting a lot of false positives, or if we want
> to turn these checks into hard pre-commit checks, we could add some
> sort of markup to allow translators to say "I know what I'm doing in
> this case". But that can be a hassle, so it's only worthwhile if we
> have a real problem with false positives.
>
> --
> Shaun
>
>
>
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
