New approach to placeholders?

[Michael Bauer]

Just finished updating some strings and noticed this batch:

checked %S
not checked %S
expanded %S
collapsed %S

Can I just register my disapproval to this approach? Splitting a noun
and an adjective like that may work in English, but not in most other
languages. The more strings like that we get, the worse the overall
language quality of the localizations will get.

Salude e trigu,

Michael

[Robert Kaiser]

Michael Bauer schrieb:

> Can I just register my disapproval to this approach? Splitting a noun
> and an adjective like that may work in English, but not in most other
> languages.

1) I'm not even sure what you are talking about here, could you explain
what the problem is?

2) What would you propose as a solution? Problems without (proposed)
solutions sound a lot like useless rants, if you want things to be
better, you need to make a first step in that direction.

Thanks,

Robert Kaiser

[Axel Hecht]

On 30.04.12 14:58, Michael Bauer wrote:
>
> 30/04/2012 13:43, sgrìobh Robert Kaiser:

>>
>> 1) I'm not even sure what you are talking about here, could you
>> explain what the problem is?

> I'm sure there have been discussions on chopping up phrases like that
> before.
>
> Take "collapsed %S". Looking at the general environment of that string,
> it looks like it will be used to produce strings like "collapsed
> cell/menu/table/label/whatever". In Gaelic, this results in
> ungrammatical combinations, for example for "collapsed label" and
> "collapsed menu" you'd want
> leubail cho-theanntaichte
> clàr-taice co-theannaichte
>
> But if you just use a formula, you only get "co-theannaichte", making
> one of them wrong.
>
> German will have the same problem, you have different case markings such
> as "markierte Box" "markiertes Menü" ...

>
>> 2) What would you propose as a solution? Problems without (proposed)
>> solutions sound a lot like useless rants, if you want things to be
>> better, you need to make a first step in that direction.
>

> - Don't use formulae like that (preferred option)
> - Ask the l10n list if it's workable in a specific scenario
>
> Michael
>

So, we're talking about
http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/accessibility/AccessFu.properties#72.

Basically, you're asking to get 4 * 65 strings strings added, sounds
rough. Might not fully explode like that, but still.

So, yes, this is a known deficiency in our (and everybody else') l10n
infra. The common way to hack around problems like this is to say

Collapsed element %S
or
Markiertes Element %S

in languages where you need that.

If we had l20n, this would be easy.

PS: Please open new threads by opening new threads, not by replying to
existing unrelated ones. Threading is a good thing to have.

Axel

[Michael Wolf]

Michael Bauer schrieb:

> Take "collapsed %S". Looking at the general environment of that string,
> it looks like it will be used to produce strings like "collapsed
> cell/menu/table/label/whatever". In Gaelic, this results in
> ungrammatical combinations, for example for "collapsed label" and
> "collapsed menu" you'd want
> leubail cho-theanntaichte
> clàr-taice co-theannaichte
>
> But if you just use a formula, you only get "co-theannaichte", making
> one of them wrong.
>
> German will have the same problem, you have different case markings such
> as "markierte Box" "markiertes Menü" ...

It can be even worse because words ending with -ed cannot be adjectives
only but verbal forms as well.

collapsed %S can also mean: klappte %S zu or hat %S zugeklappt.

Here the subject of the sentence is missing and can be in another string
which is e.g. "user" or "administrator". But a translator doesn't see
that both strings belong together.

But I have good experience with localization notes in locale files of
Mozilla programs. I translate GUI for Wikipedia as well and there are
thousands of strings. Unfortunately a lot of them are such "lego"
strings as well.

Regards
milupo

[Eduardo Trápani]

> So, yes, this is a known deficiency in our (and everybody else') l10n
> infra. The common way to hack around problems like this is to say
>
> Collapsed element %S
> or
> Markiertes Element %S
>
> in languages where you need that.

It's ok once you understand that it is an adjective and not a verbal
form ... For "expanded %S" I still don't know if it means that it is
expanded or that it has been expanded.

I guess we cannot ask for a more verbose English version, but a
localization note stating the intended meaning and the possible set of
values, would be great. I like localization notes, I think they serve
us well.

In this case something along the lines of:

# LOCALIZATION NOTE: this is the result of an invoked action. %S is an
element name.

Patch attached. I can file a bug once we agree on the localization note.

I think it wouldn't hurt though to bring up this issue somewhere else.
Maybe here[1] (Writing Localizable Code - MDN) would be a good place.
"Lego" strings are in fact a special case of "Try not to assume grammar
in composite strings", but since that might not be that obvious, I'd
rather mention it explicitly. This is my proposal, feel free to edit:

BEGIN
* Beware of placeholders
Just as in composite strings, a placeholder might make assumptions on
grammar. For example in the string "Empty %S", the translation for
"Empty" for certain languages might be different depending on whether %S
is a masculine or a feminine noun, but you are forcing the translator to
choose one.
END

Then we could also try to spot those "composite strings" and make sure
they all have a descriptive localization note, or comment.

Eduardo.

[1] https://developer.mozilla.org/en/Writing_localizable_code

[Michael Bauer]

30/04/2012 14:33, sgrìobh Axel Hecht:

>
> Basically, you're asking to get 4 * 65 strings strings added, sounds
> rough. Might not fully explode like that, but still.

Interesting question actually, how many *does* it produce and was this
possibly just a case of laziness?

>
> So, yes, this is a known deficiency in our (and everybody else') l10n
> infra. The common way to hack around problems like this is to say
>
> Collapsed element %S
> or
> Markiertes Element %S
>
> in languages where you need that.

That might be doable if I knew that that's what it's supposed to
produce. Usually it's just lego (as Eduardo called it) with no guidance.

>
> If we had l20n, this would be easy.

Perhaps it's time for l20n? Surely it can't be deferred forever.

>
> PS: Please open new threads by opening new threads, not by replying to
> existing unrelated ones. Threading is a good thing to have.

Sorry, I'm not following... I started a totally new string called "New
approach to placeholders?", I wasn't replying to anything unless I just
happen to have named it after some debate that had taken place some
other time.

Michael

[Rimas Kudelis]

Hi Axel,

2012.04.30 16:33, Axel Hecht rašė:
> So, we're talking about
> http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/accessibility/AccessFu.properties#72.
>
>
> Basically, you're asking to get 4 * 65 strings strings added, sounds
> rough. Might not fully explode like that, but still.

Let me disagree:
a) this growth is not exponential. It's of course much more than 4 + 65,
but this amount of strings is still manageable.
b) it seems that these are relatively easy strings. Grouping them
logically would make their localisation a piece of cake.

> So, yes, this is a known deficiency in our (and everybody else') l10n
> infra. The common way to hack around problems like this is to say
>
> Collapsed element %S
> or
> Markiertes Element %S
>
> in languages where you need that.

We all know that this way is suboptimal and should be avoided whenever
possible. 4 * 65 sounds quite possible to me.

Rimas

[vito....@gmail.com]

On Monday, April 30, 2012 1:39:51 PM UTC+2, Michael Bauer wrote:
> Just finished updating some strings and noticed this batch:
>
> checked %S
> not checked %S
> expanded %S
> collapsed %S
>

adding some feed to this fire, It I remember correctly (or, as Italians would say: maybe its not true, but it makes a fine story) I localized it all as %S standing for a number - as is "15 have been checked and 10 have been not" -.

Regards

Vito

[vito....@gmail.com]

On Monday, April 30, 2012 1:39:51 PM UTC+2, Michael Bauer wrote:

> Just finished updating some strings and noticed this batch:
>
> checked %S
> not checked %S
> expanded %S
> collapsed %S
>

[Robert Kaiser]

Michael Bauer schrieb:

> 30/04/2012 14:33, sgrìobh Axel Hecht:

>> If we had l20n, this would be easy.
> Perhaps it's time for l20n? Surely it can't be deferred forever.

Work is being done on it, but it hit some snags - apparently everyone
coming into the discussion of it is re-questioning most of the decisions
that have already been made on the format, sometimes saying "our product
can't use it unless you change <pet style nit here>". :(

Robert Kaiser

[Eduardo Trápani]

> adding some feed to this fire, It I remember correctly (or, as Italians
> would say: maybe its not true, but it makes a fine story) I localized it all
> as %S standing for a number - as is "15 have been checked and 10 have been
> not" -.

I'd love to hear your say on the two proposals I made[1]. One for a
localization note that would have helped you (or the guy in the story
:)) and one to add a paragraph to discourage the use of such strings
in the MDN documentation.

I think that just stating the known problem over and over gets us nowhere.

The patch in [1] creates a localization note, if anybody else comes up
with alternative English strings, please submit them. Let's solve it
and try to prevent it from happening in the future!

Eduardo.

[1] http://groups.google.com/group/mozilla.dev.l10n/msg/9a785903a4e1f2d0

[Michael Bauer]

Well, it's good to hear something is happening.

May I ask though if that team (I've never heard of the mozilla l20n
team, sorry) involved any professional linguists?

Michael

01/05/2012 18:36, sgrìobh Robert Kaiser:

[flod]

Il 01/05/12 20.50, Michael Bauer ha scritto:

> Well, it's good to hear something is happening.
> May I ask though if that team (I've never heard of the mozilla l20n
> team, sorry) involved any professional linguists?

There's a mailing list, even if it's not extremely active
https://groups.google.com/forum/?fromgroups#!forum/localization-20

To get back in topic, I don't think that moving from 65 strings to 260
would really be that manageable.

Not really knowing much about other languages except for en (and maybe
fr/es), would it be possible to make it "less wrong" using a structure
like "Item %S (checked)", so that you can decline the adjective
according to the noun "item"?

Francesco

[Michael Bauer]

Maybe this has gone under... my question was, does that team have any
linguists on it? Something that looks like a real toughie to
non-linguists might be pie to someone from "the dark side" on languages :)

Michael

01/05/2012 18:36, sgrìobh Robert Kaiser:
>
>

[Armen Zambrano G.]

On 12-04-26 2:20 PM, Axel Hecht wrote:
> On 26.04.12 20:18, Hasse wrote:
>> In article <Y5idnYc1sYDX5QTS...@mozilla.org>, Jeff Beatty
>> wrote...
>>>
>>> Attention all localizers!
>>>
>>> The time to localize Fennec has come.
>>
>> Will you now accept new localizations, or is that still not possible?
>>
>
> We're accepting new locales, yeah.
>
> Axel
>
Armenian would like to take part of this.
What is the process?
We have signed off Aurora.

cheers,
Armen

[1] https://l10n.mozilla.org/shipping/signoffs/hy-AM/fennec-aurora

[flod]

Il 01/05/12 19.15, Rimas Kudelis ha scritto:

> a) this growth is not exponential. It's of course much more than 4 +
> 65, but this amount of strings is still manageable.

Hi Rimas,
I thought this was a typo (4+65), but I read you again in the bug [1]
and I think you're wrong.

65 strings + 4 variants (checked, not checked, collapsed, expanded). If
you want to support cases and genders, you'll end up with at least 65*2
(120) strings, not 65+4 or a few more, assuming that only two states
apply to a single element (which I'm not sure of).

"checkbox" is translated as a female word in Italian, how can you know
which gender "checked" should be? The only way is to have a "checkbox
checked", "checkbox unchecked", and so on for all elements.

Francesco

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=746930#c37

[Rimas Kudelis]

Hi Francesco,

flod wrote:
> Il 01/05/12 19.15, Rimas Kudelis ha scritto:
>> a) this growth is not exponential. It's of course much more than 4 +
>> 65, but this amount of strings is still manageable.
>

> I thought this was a typo (4+65), but I read you again in the bug [1]
> and I think you're wrong.

No, it's not a typo.

> 65 strings + 4 variants (checked, not checked, collapsed, expanded). If
> you want to support cases and genders, you'll end up with at least 65*2
> (120) strings, not 65+4 or a few more, assuming that only two states
> apply to a single element (which I'm not sure of).

I was comparing 4 * 65 (the number of composed string variants) to 4 +
65 (which I assume is the current status, I haven't looked at the
strings yet, TBH). 260 looked manageable to me, but if the number of
precomposed strings would be closer to 130, it's even better.

> "checkbox" is translated as a female word in Italian, how can you know
> which gender "checked" should be? The only way is to have a "checkbox
> checked", "checkbox unchecked", and so on for all elements.

I'm all in favor of precomposed strings. Perhaps I wasn't clear enough
about it?

Rimas