How can I translate Seamonkey? I'l like to have a English version as
opposed to an American version, especially for the address book - ZIP
codes and States don't exist in my part of the world ;-)
Is it difficult to do? Does it require a lot of time? Would there be
deadlines to meet or could I translate it at my own pace? Do I need to
have access to something like MS Developer Studio or anything, I'm not
really a programmer.

11/25/2005 05:54 pm, Stephen thus wrote :
How can I translate Seamonkey? I'l like to have a English version as
opposed to an American version, especially for the address book - ZIP
codes and States don't exist in my part of the world ;-)

Is it difficult to do? Does it require a lot of time? Would there be
deadlines to meet or could I translate it at my own pace? Do I need to
have access to something like MS Developer Studio or anything, I'm not
really a programmer.
Hehehe It's funny how we really do speak different languages,
Stephen. ;-)

Check out

I think the file you're looking to mod would be in chrome/messenger.jar.
Look for and
and their relevant
js files.

Also, check out the Mozilla Localization Project:

Good luck!

11/25/2005 05:54 pm, Stephen thus wrote :
How can I translate Seamonkey? I'l like to have a English version as
opposed to an American version, especially for the address book - ZIP
codes and States don't exist in my part of the world ;-)

Is it difficult to do? Does it require a lot of time? Would there be
deadlines to meet or could I translate it at my own pace? Do I need to
have access to something like MS Developer Studio or anything, I'm not
really a programmer.

the obvious:

Lewis Rosenthal wrote:
11/25/2005 05:54 pm, Stephen thus wrote :
>How can I translate Seamonkey? I'l like to have a English version as
>opposed to an American version, especially for the address book - ZIP
>codes and States don't exist in my part of the world ;-)
>>
>Is it difficult to do? Does it require a lot of time? Would there be
>deadlines to meet or could I translate it at my own pace? Do I need to
>have access to something like MS Developer Studio or anything, I'm not
>really a programmer.

the obvious:

<grinAs soon as the dust settles from the Fx release, I'll be digging
out, dusting off and updating the SM localisation I made in about March
of this year (NB my user-agent string is lying). Tuits are in rather
short supply currently, though.

regards,
Mark

11/28/2005 07:38 am, Mark Tyndall thus wrote :
Lewis Rosenthal wrote:

<snip>

>the obvious:
>>
>

<grinAs soon as the dust settles from the Fx release, I'll be digging
out, dusting off and updating the SM localisation I made in about March
of this year (NB my user-agent string is lying). Tuits are in rather
short supply currently, though.

Hehehe I know what you mean about a shortage of tuits. ;-)

Actually, I was quite surprised by the lack of bugs on Bugzilla for
something like this. I know that I tend to be rather US-centric (well, I
live here), but even I must admit that not having a way to change the
address card fields to better match other countries' standards is kind
of broken. course, this may become less of an issue after the/a
unified storage system is implemented (see:
). Assuming Moz 2.0
would implement this system-wide, I could see the ability to label and
rearrange the address card fields per the user's taste.

Further, I have an even bigger gripe with this current lack of
flexibility. I have several friends across the Pond (UK, Germany,
Netherlands, etc.). It would be nice if I could use appropriate fields
for these addresses, and simply hide the ones (in the UI) I don't use
for them.

Cheers, Mark. :-)

/Lewis Rosenthal/:

course, this may become less of an issue after the/a
unified storage system is implemented (see:
). Assuming Moz 2.0
would implement this system-wide, I could see the ability to label and
rearrange the address card fields per the user's taste.

I fail to get how the "Unified Storage" would help the localization.

11/29/2005 02:01 pm, Stanimir Stamenkov thus wrote :
/Lewis Rosenthal/:

>course, this may become less of an issue after the/a unified
>storage system is implemented (see:
>). Assuming Moz 2.0
>would implement this system-wide, I could see the ability to label and
>rearrange the address card fields per the user's taste.

I fail to get how the "Unified Storage" would help the localization.

The idea would be that *everything* - including address book data -
would get stored in an SQLite database. I realize that the wiki is
mainly concerned with system data (chrome registry, prefs, etc.), but
the idea is the same. the form data itself is separated from the
chrome, then it's a simple matter of changing the field descriptions in
the db.

/Lewis Rosenthal/:
11/29/2005 02:01 pm, Stanimir Stamenkov thus wrote :
>
>I fail to get how the "Unified Storage" would help the localization.
>
The idea would be that *everything* - including address book data -
would get stored in an SQLite database. I realize that the wiki is
mainly concerned with system data (chrome registry, prefs, etc.), but
the idea is the same. the form data itself is separated from the
chrome, then it's a simple matter of changing the field descriptions in
the db.

I still fail to see how the method of storing preferences and user
data helps the localization. Looking back at your previous message I
see you want some specific features regarding recipients (as for
mail) or targets for some action (like one may define multiple
identities for mail/news account, which may are defined in different
languages) but as far as I understand the "Unified Storage" is no
way particular for storing such feature settings, but just settings.

11/30/2005 03:48 pm, Stanimir Stamenkov thus wrote :
/Lewis Rosenthal/:
>11/29/2005 02:01 pm, Stanimir Stamenkov thus wrote :
>>
I fail to get how the "Unified Storage" would help the localization.
>>
>The idea would be that *everything* - including address book data -
>would get stored in an SQLite database. I realize that the wiki is
>mainly concerned with system data (chrome registry, prefs, etc.), but
>the idea is the same. the form data itself is separated from the
>chrome, then it's a simple matter of changing the field descriptions
>in the db.

I still fail to see how the method of storing preferences and user data
helps the localization.

I'm truly sorry to hear that, Stanimir.

Looking back at your previous message I see you
want some specific features regarding recipients (as for mail) or
targets for some action (like one may define multiple identities for
mail/news account, which may are defined in different languages)

No, I was responding to Stephen's original question, which was:

How can I translate Seamonkey? I'l like to have a English version
as opposed to an American version, especially for the address book
- ZIP codes and States don't exist in my part of the world

His point was that while American English and UK English share a similar
lexicon, we have different addressing standards. The reference I made to
the unified storage entry in the wiki was merely a musing as to how much
more flexible the addressbook - as well as other areas of the program -
could be, if headings and such weren't hardcoded into the application,
but rather, became database field names (well, to be sure, they are
indeed database field names, but currently, there's no way to change
them without going through the whole localization process, and
recompiling the program).

but as
far as I understand the "Unified Storage" is no way particular for
storing such feature settings, but just settings.

What I said in my reply to your query was clear:

The idea would be that *everything* - including address book data -
would get stored in an SQLite database.

I didn't say that the wiki stated that. If it would make folks feel more
comfortable, I'll go add that comment to the wiki, but I'm sure it's not
an original idea, and frankly, we all have too much stuff to read as it
is! :-)