Sorry about those disappearing accountCreation Thunderbird files
Phil Ringnalda
If you looked over the last couple of days, there were four new files
for Thunderbird, accountCreation.dtd, accountCreation.properties,
accountCreationModel.properties and accountCreationUtil.properties, and
if you looked closely, they included some strings, like a URL with /XXX/
in it, that you would have had no idea what we were thinking when we
told you to localize it.
We didn't actually intend to put those where you would see them, since
we were just landing the code to not have to keep dealing with a monster
patch. I moved them over to /mail/base/content/ where they'll be out of
your way until we get them polished up a bit. They should be back before
too long, we hope without so many awkward bits.
(I'm curious about something, from one of them: just how horrible a
string to translate is "enum_value.error=enum value not supported"?)
Ricardo Palomares Martínez
> Sorry, we screwed up.
>
> If you looked over the last couple of days, there were four new files
> for Thunderbird, accountCreation.dtd, accountCreation.properties,
>
> We didn't actually intend to put those where you would see them, since
> we were just landing the code to not have to keep dealing with a monster
> patch. I moved them over to /mail/base/content/ where they'll be out of
> your way until we get them polished up a bit. They should be back before
> too long, we hope without so many awkward bits.
Will the files hopefully come back to the same directory with the same
names (although with changes, of course)? :-)
> (I'm curious about something, from one of them: just how horrible a
> string to translate is "enum_value.error=enum value not supported"?)
When I saw it, I remember that I thought not so much about the
difficulty to translate it (it is pretty straightforward to me), but
the difficulty for a normal user to understand what a "enum value" is
at all, whether he speaks english or spanish. There are "string"
appearances that may be not familiar to non-programmers, I'd say.
Ricardo
Phil Ringnalda
> Will the files hopefully come back to the same directory with the same
> names (although with changes, of course)? :-)
Mostly, at least: I'm not absolutely sure that the Model.properties and
Util.properties will make sense as separate files, depending on what
ends up in them.
>> (I'm curious about something, from one of them: just how horrible a
>> string to translate is "enum_value.error=enum value not supported"?)
>
>
> When I saw it, I remember that I thought not so much about the
> difficulty to translate it (it is pretty straightforward to me), but
> the difficulty for a normal user to understand what a "enum value" is
> at all, whether he speaks english or spanish. There are "string"
> appearances that may be not familiar to non-programmers, I'd say.
Yeah, that's part of the fun of those: they aren't actually for users,
they are for people writing config files (like
https://live.mozillamessaging.com/autoconfig/t-online.de%20free). If
that config file had <socketType>goats</socketType> instead of plain,
then there would be an "Error: (your translated string here)" message in
the error console.
I understand the theory behind that, because we want only
partly-technical people all over the world to write config files, but
I'm still not sure how great an idea it really is.
Robert Kaiser
> I understand the theory behind that, because we want only
> partly-technical people all over the world to write config files, but
> I'm still not sure how great an idea it really is.
For reference, we even have all the kinds of XML, JS and CSS error
messages and such stuff localized in the error console. Not sure how
feasible it is overall, but it's surely common style to do it.
Robert Kaiser
Axel Hecht
Yeah, and at some point I should actually file bugs about suggesting to
not translate those files, at least for languages in which no
native-language support community exists for those standards.
"enum value not supported" as sole display is utterly useless, tbh. A
good error message would be something like "socketType in configuration
... should be one of 'plain', '...'" or something constructive.
Axel
Phil Ringnalda
> On 14.04.2009 15:35 Uhr, Robert Kaiser wrote:
>> For reference, we even have all the kinds of XML, JS and CSS error
>> messages and such stuff localized in the error console. Not sure how
>> feasible it is overall, but it's surely common style to do it.
Yeah, I should have remembered that, having had to retranslate back to
figure out what code a bug report was hitting. After looking at what's
included (mmm, 5 whole strings about imagemaps in
layout_errors.properties, and one of the 8 strings in webservices'
security.properties landed unused in 2003 (is it even possible to build
webservices anymore?) and has been translated hundreds of times since),
I'm no more sure than I was before. And you don't actually mean "JS" do
you? I don't see any place or way that js.msg would be localized.
> "enum value not supported" as sole display is utterly useless, tbh. A
> good error message would be something like "socketType in configuration
> ... should be one of 'plain', '...'" or something constructive.
There's no end to the fun: the message is actually "{your translation of
'enum value not supported'} (bad value: goats)" with an English "bad
value," but only if you have kDebug = true, which also triggers massive
dump()age, so we won't ship with it true. So... strings dragged back to
content, vague questions asked in .l10n.