MozillaWiki - User contributions [en]

User:Jag/MercurialConfig

2009-04-14T01:40:09Z

Jag:

[ui]
username=Your Name <you@example.com>

[defaults]
# Needed for Mercurial < 1.2?
#diff=-U 8 -p
#qdiff=-U 8

[diff]
git=true
showfunc=true
unified=8

[extensions]
hgext.color=
hgext.extdiff=
hgext.mq=
hgext.rebase=

[extdiff]
cmd.diffw=diff
opts.diffw=-wrNpU8

[hooks]
# Prevent "hg pull" if MQ patches are applied.
prechangegroup.mq-no-pull = ! hg qtop > /dev/null 2>&1
# Prevent "hg push" if MQ patches are applied.
preoutgoing.mq-no-push = ! hg qtop > /dev/null 2>&1

User:Jag

2009-04-13T23:51:02Z

Jag:

My [[User:Jag/MercurialConfig|.hgrc]]

User:Jag/MercurialConfig

2009-04-13T23:49:43Z

Jag:

[ui]
username=Your Name <you@example.com>

[defaults]
# Needed for Mercurial < 1.2?
#diff=-U 8 -p
#qdiff=-U 8

[diff]
git=true
showfunc=true
unified=8

[extensions]
hgext.rebase=
hgext.mq=
extdiff=

[extdiff]
cmd.diffw=diff
opts.diffw=-wrNpU8

[hooks]
# Prevent "hg pull" if MQ patches are applied.
prechangegroup.mq-no-pull = ! hg qtop > /dev/null 2>&1
# Prevent "hg push" if MQ patches are applied.
preoutgoing.mq-no-push = ! hg qtop > /dev/null 2>&1

User:Jag/MercurialConfig

2009-04-13T23:46:39Z

Jag: Created page with '[ui] username=Your Name <you@example.com> [defaults] # Needed for Mercurial < 1.2? #diff=-U 8 -p #qdiff=-U 8 [diff] git=true showfunc=true unified=8 [extensions] hgext.rebase=...'

User:Jag

2009-04-13T23:44:17Z

Jag: Created page with 'Nothing'

Nothing

Mozilla 2/Strings/Static Analysis

2008-02-12T13:55:13Z

Jag: Alright, let's try this wording.

== How many strings exist *only* for conversion? ==

Procedure:

* find calls to NS_ConvertUTF8toUTF16 and CopyUTF8toUTF16
* check to see whether that string is modified after the conversion takes place

TODO: define "modification"

repeat for utf16->ut8

== If "AString" were immutable, where would we fail? ==

Imagine that all nsAStrings currently allocated on the stack became a different type (nsAStringBuilder or std::wstring or something). But when we pass strings around, they are immutable. Classify any cases where this wouldn't work:

Take the following methods:

<pre>
nsresult GetAString(nsAString &result)
{
result.Assign("foo"); // this is ok, it can be converted to return a new
// immutable string
}

nsresult AppendToAString(nsAString &result)
{
result.Append("foo"); // this won't work... it modifies the inout param so
// we would have to rewrite "result" to be
// nsAStringBuilder&, or split it into two separate
// params, one in, one out.
}
</pre>

Mozilla 2/Strings/Static Analysis

2008-02-12T13:48:55Z

Jag: /* If "AString" were immutable, where would we fail? */ Clarify comments

== How many strings exist *only* for conversion? ==

Procedure:

* find calls to NS_ConvertUTF8toUTF16 and CopyUTF8toUTF16
* check to see whether that string is modified after the conversion takes place

TODO: define "modification"

repeat for utf16->ut8

== If "AString" were immutable, where would we fail? ==

Imagine that all nsAStrings currently allocated on the stack became a different type (nsAStringBuilder or std::wstring or something). But when we pass strings around, they are immutable. Classify any cases where this wouldn't work:

Take the following methods:

<pre>
nsresult GetAString(nsAString &result)
{
result.Assign("foo"); // this works... we would merely be returning a new
// immutable value in the outparam
}

nsresult AppendToAString(nsAString &result)
{
result.Append("foo"); // this won't work... it modifies the inout param so
// we would have to rewrite "result" to be
// nsAStringBuilder&
}
</pre>

Talk:Mozilla 2/Strings/Static Analysis

2008-02-12T13:47:46Z

Jag:

From the given examples, it seems as if you're talking about the buffer being immutable, not the string object itself. [Update] I see now that with "this is ok" is meant "this works" --jag

Talk:Mozilla 2/Strings

2008-02-11T11:50:14Z

Jag: New page: What exactly makes our string classes a barrier for new developers? Is it the names (the C in *CString is misleading), the specialized string types (can/should we get rid of nsDependentStr...

What exactly makes our string classes a barrier for new developers? Is it the names (the C in *CString is misleading), the specialized string types (can/should we get rid of nsDependentString, nsAutoString, nsPrintfCString?), or the concepts ((extended) ascii vs utf-8 vs utf-16 vs unicode, what to use where, how to convert, etc.)? Or all of those, and more?

Personally I would love it if we had one string type (utf-8 or utf-16), everything else (encoding/charset-wise) gets converted as early as possible. If we choose to have both (could the second one be restricted to certain areas?), use something other than C or W (like say 8 and 16) to indicate which class is which, and I would avoid automatic conversions (they're tempting though) so you don't get hidden performance drag. --jag

Talk:Mozilla 2/Strings/Static Analysis

2008-02-11T11:33:36Z

Jag: New page: From the given examples, it seems as if you're talking about the buffer being immutable, not the string object itself. --jag

From the given examples, it seems as if you're talking about the buffer being immutable, not the string object itself. --jag

Mozilla 2/Strings/Dynamic Analysis

2008-02-11T11:29:38Z

Jag: /* Conversion counts */ fix typo

<< back to [[Mozilla 2/Strings]]

== The cost/benefit of UTF8 ==

Question: If we moved from our current UCS2/UTF16 storage for nsAString to UTF8, what would the impact be on memory usage?

Procedure:

Instrument [http://mxr.mozilla.org/mozilla/source/xpcom/string/public/nsStringBuffer.h nsStringBuffer] with a large linked-list (with locking and all that good stuff). Run the instrumented browser and collect data about all nsStringBuffers which hold PRUnichar data:

* What is the size of the buffer
* What would the size of the buffer be in UTF8?
* Is the buffer pure-ASCII?

== Conversion counts ==

Question: how much do we currently convert between UTF8 and UTF16?

Procedure:
Instrument the number of calls to [http://mxr.mozilla.org/mozilla/source/xpcom/string/public/nsUTF8Utils.h#459 ConvertUTF8toUTF16] and [http://mxr.mozilla.org/mozilla/source/xpcom/string/public/nsUTF8Utils.h#611 ConvertUTF16toUTF8].

Bonus points: group and identify common callstacks

== Autostring value ==

* Dynamic analysis: autostring buffer-copy counts (are autostrings worthwhile)?

Procedure: todo

Mozilla 24

2007-09-11T08:42:35Z

Jag: /* Definitely */ add myself

[[Image:H1_mozilla24s.jpg]]

'''[http://www.mozilla24.com/en-US/ Mozilla 24]''' is a worldwide, 24-hour open discussion that connects community members, academics and Web visionaries from Asia, America and Europe, in person and over the broadband video WIDE network.

The event will feature industry leaders who will present on Web trends and technologies that will help shape the future of the Web.

Current speakers include:

* [http://www.google.com/corporate/execs.html#vint Dr. Vint Cerf], Vice President and Chief Internet Evangelist at Google Inc.
* [http://www.law.stanford.edu/directory/profile/39/ Dr. Lawrence Lessig], professor of law at Stanford Law School and founder of its Center for Internet and Society
* [http://www.icann.org/biog/murai.htm Dr. Jun Murai], professor of Faculty of Environment and Information Studies and Vice President at Keio University
* [http://cs.senecac.on.ca/~david.humphrey/composite.html Dr. David Humphrey], professor at the School of Computer Studies at Seneca College, Toronto, Canada
* [http://en.wikipedia.org/wiki/Mitchell_Baker Mitchell Baker], Chief Executive Officer, Mozilla Corporation
* [http://en.wikipedia.org/wiki/Mike_Shaver Mike Shaver], Chief Evangelist, Mozilla Corporation
* [http://en.wikipedia.org/wiki/Tristan_Nitot Tristan Nitot], President of Mozilla Europe
* [http://www.mozilla24.com/members/greeting.html#entry-5 Satoko Takita], Chair of the Board of Mozilla Japan

Be a part of our inaugural event - whether online or at one of the locations in Japan, Paris or the San Francisco Bay Area. Space is limited so register now!

'''[http://www.mozilla24.com/en-US/ Visit the Mozilla 24 site]'''

= Palo Alto, California =

Mozilla 24 will be held on Sept. 15, 2007 at Stanford University's Wallenberg Hall. '''[http://www.mozilla24.com/en-US/programs/stanford/ Sessions and Agenda]'''

= Paris, France =

September 15th, 10:15am – 1:00pm (CEST)

[http://www.enst.fr/ ENST], École Nationale Supérieure de Télécommunications

Amphithéatre Emeraude

49 rue Vergniaud

75013 Paris

Métro stations: Corvisart or Glacière

Location and program details here: http://www.mozilla24.com/en-US/programs/paris/

= Pathumthani, Thailand =

[http://www.ait.ac.th/ AIT] - Asian Institute of Technology

Pathumthani 12120

THAILAND

== Sign-up ==

Please sign up below to attend our in-person event at Stanford and use the template provided, as it will make it much easier for us to work with the data. Thanks!

You can also sign up at [http://upcoming.yahoo.com/event/241294/ upcoming.org].

Please note: This will be a live, public, recorded event. You acknowledge that if you participate, your image may be included in any recording of the event, and the recording may be later broadcast or otherwise shown publicly and/or electronically.

=== Definitely ===
{{DevDayAttendee|John W Lockwood|jwlockwd|Stanford University|NetFPGA Chief Evanglist}}
{{DevDayAttendee|Mike Shaver|shaver|add-ons, MDC|your cruise director}}
{{DevDayAttendee|Alex Vincent|WeirdAl|editing/DOM/XUL enthusiast|fullmetal alchemist}}
{{DevDayAttendee|Myk Melez|myk|microsummaries, site-specific prefs, Forumzilla|conundrum}}
{{DevDayAttendee|Matthew Gertner|plasticmillion|AllPeers, MozPad|jetlagged}}
{{DevDayAttendee|Cedric Maloux|cmaloux|AllPeers CEO|no really, I have a degree in Computer Science}}
{{DevDayAttendee|Sarah Wilson|sarah1847|archivist, librarian|wikicurious}}
{{DevDayAttendee|Window Snyder|window|security|}}
{{DevDayAttendee|Carl Smith|CEO TrendVentures|SAAS & Other Cool Lifestyle Products|}}
{{DevDayAttendee|Mikeal Rogers|mikeal|Open Source Applications Foundation|QA Python Developer|}}
{{DevDayAttendee|Adam Christian|Open Source Applications Foundation|QA JavaScript Developer|}}
{{DevDayAttendee|Pascal Chevrel|weblocalization|community|}}
{{DevDayAttendee|Paul Kim|marketing|Spread Firefox!|}}
{{DevDayAttendee|Seth Bindernagel|sethb|community|community|}}
{{DevDayAttendee|Tim Riley|timr|testing|community building|}}
{{DevDayAttendee|Axel Hecht|Pike|localization coordinator|}}
{{DevDayAttendee|Alix Franquet|alix|marketing|}}
{{DevDayAttendee|Raymond Etornam Agbeame|Campus Representative|community|}}
{{DevDayAttendee|Melissa Shapiro|shappy|pr|}}
{{DevDayAttendee|Rebecca Silliman|Outcast Communications|pr|}}
{{DevDayAttendee|Jessica Waight|Outcast Communications|pr|}}
{{DevDayAttendee|Kristen Whisenand|Outcast Communications|pr|}}
{{DevDayAttendee|Matt Crocker|mattc|Songbird Developer|}}
{{DevDayAttendee|Dana Oshiro|Hiyaa|PR|}}
{{DevDayAttendee|Johnathan Nightingale|johnath|Security UI|human shield}}
{{DevDayAttendee|Ian McKellar|ianloic|Songbird Developer|etc}}
{{DevDayAttendee|Alex Faaborg|faaborg|user experience designer|}}
{{DevDayAttendee|Dave Nielsen|dnielsen|Strikeiron Partner/Developer Programs|}}
{{DevDayAttendee|Charles-H. Schulz|Charles|Lead of the Native-Language Confederation, OpenOffice.org|}}
{{DevDayAttendee|Justin Dolske|dolske|Firefox developer|}}
{{DevDayAttendee|Vishal Malik|CTO|Vbune|Virtual Brain Tuning|}}
{{DevDayAttendee|Dick Hardt|CEO|Sxip Identity|Firefox add-ons, Sxipper, OpenID|}}
{{DevDayAttendee|Oladayo Olagunju|Techtain||}}
{{DevDayAttendee|Joe Smith|Yasumoto|Chapman University|Computer Science Major|}}
{{DevDayAttendee|Ahmed Aljunied|ahmedaljunied|L2 Solutions|Developer}}
{{DevDayAttendee|Chu Lim|Intel||Compiler developer}}
{{DevDayAttendee|Peter R Annema|jag|SeaMonkey hacker|What harm is a man with a broom?}}

=== Probably (logistics) ===
"I'll be attending if I can sort out travel and timing."

{{DevDayAttendee|Nancy Tubbs|FullCalendar|developer|}}
{{DevDayAttendee|Petr Kral|Co-Founder & CEO|Skillr|}}
{{DevDayAttendee|Tomas Zeman|Co-Founder|Wirenode|}}

=== Regrets ===
"I'd like to have been there, but I have other commitments, or a severe allergy to lizard-logo T-shirts."

{{DevDayAttendee|Terry Chay|tychay|software architect, Tagged, Lunch 2.0, PHP Group|Going to invite everyone instead}}

L20n/Background

2007-08-18T13:45:02Z

Jag: /* English sample */ Added in daisies sample

{{draft}}

When writing localizable software, in particular in an environment based on a toolkit, software authors and localizers are facing composited strings in the UI. Samples would be strings composited out of templates and computed data like in an address or a generic toolkit error message.

Localizers are facing three major challenges in this context:

# The string composition code includes assumptions on the grammar or composition of text.
# Different plural forms depending on a value.
# Different grammatical forms, depending on a given value.

The first item really just covers annoying bugs in the software, but they are way too common, and thus listed.

The second and third items are a tad more tricky, so let's make an example. It's based on two rather unfounded assumptions, firstly, that Jägermeister is such a gross drink that it would be of male gender anywhere in the world, and that daisies are cute enough to be female.

=== English sample ===
10 small Jägermeister hang around. 
9 small Jägermeister hang around. 
''... English is a bore ...'' 
1 small Jägermeister hangs around. 
Head off and order new ones!

The same with daisies:

10 small daisies hang around. 
''... well, yeah, dito ...'' 
1 small daisy hangs around. 
Head off and protect your environment!

Now for the same in German (which is still pretty darn simple)

=== German sample ===
10 kleine Jägermeister standen rum. 
''... German is a bore ...''
1 kleiner Jägermeister stand rum. 
Bestelle eine neue Runde!

10 kleine Butterblümchen standen rum. 
''... still ...''
1 kleines Butterblümchen stand run. 
Es ist Zeit für ein bisschen Umweltschutz!

Let's leave the zero value out for this discussion for the moment, because I really just entered fun values there. Let's assume that we're in the scenario of a generic toolkit message, and ''Jägermeister'' and ''daisy'' would be product specific. You could just as well think ''Firefox'' and ''Thunderbird''. Let's have two variables in this sample, ''name'' for ''Jägermeister'' or ''daisy'' and ''number'' for the values from 10 to 1.

For positive integers, gettext offers a reasonable approach, i.e., you have a macro that returns an index based on a number, and you use that to index an array. gettext does not offer a solution for the grammar and gender problems in this example, though.

For the given languages (and most languages, really), you need to know the gender of ''name'' to create the right composed string. In the common scenario that the value of ''name'' is actually in the localization data of your application, the localizer should know the gender. For other scenarios, there may be hints from the application for common requests like this. In a CRM application, for example, extracting the gender of a contact person shouldn't be the problem. In the generic case, localizers will have to work around the lack of information like they do today. There's no way to tell the gender of a person called "Andrea" or "Mic", or "Moon".

Going back to the three target audiences, the intent of this approach is to shield as much detail of a particular language from the application logic. Thus, no software author should ever see how many grammar variations the currently chosen language would have, all this information should be strictly encapsulated within the localization and the localization library. In addition, it is subject of the third group, people knowing internals of quite a bunch of languages, to create a set of properties and values to be used by applications to mark up for example the gender of an item.

Going back to the zero terms for this example, for a known finite set of values, even this odd-looking case can be handled.

Back to [[L20n]]...

[[category:L20n|Background]]

L20n/Background

2007-08-18T06:43:54Z

Jag: /* German sample */ More of same

{{draft}}

When writing localizable software, in particular in an environment based on a toolkit, software authors and localizers are facing composited strings in the UI. Samples would be strings composited out of templates and computed data like in an address or a generic toolkit error message.

Localizers are facing three major challenges in this context:

# The string composition code includes assumptions on the grammar or composition of text.
# Different plural forms depending on a value.
# Different grammatical forms, depending on a given value.

The first item really just covers annoying bugs in the software, but they are way too common, and thus listed.

The second and third items are a tad more tricky, so let's make an example. It's based on two rather unfounded assumptions, firstly, that Jägermeister is such a gross drink that it would be of male gender anywhere in the world, and that daisies are cute enough to be female.

=== English sample ===
10 small Jägermeister hang around. 
9 small Jägermeister hang around. 
''... English is a bore ...'' 
1 small Jägermeister hangs around. 
Head off and order new ones!

The same with daisies:

10 small daisies hang around. 
''... well, yeah, dito ...'' 
1 small daisy hangs around. 
Head off and protect your environment!

Now for the same in German (which is still pretty darn simple)

=== German sample ===
10 kleine Jägermeister standen rum. 
''... German is a bore ...'' 
1 kleiner Jägermeister stand rum. 
Bestelle eine neue Runde!

10 kleine Butterblümchen standen rum. 
''... still ...'' 
1 kleines Butterblümchen stand run. 
Es ist Zeit für ein bisschen Umweltschutz!

Let's leave the zero value out for this discussion for the moment, because I really just entered fun values there. Let's assume that we're in the scenario of a generic toolkit message, and ''Jägermeister'' and ''daisy'' would be product specific. You could just as well think ''Firefox'' and ''Thunderbird''. Let's have two variables in this sample, ''name'' for ''Jägermeister'' or ''daisy'' and ''number'' for the values from 10 to 1.

For positive integers, gettext offers a reasonable approach, i.e., you have a macro that returns an index based on a number, and you use that to index an array. gettext does not offer a solution for the grammar and gender problems in this example, though.

For the given languages (and most languages, really), you need to know the gender of ''name'' to create the right composed string. In the common scenario that the value of ''name'' is actually in the localization data of your application, the localizer should know the gender. For other scenarios, there may be hints from the application for common requests like this. In a CRM application, for example, extracting the gender of a contact person shouldn't be the problem. In the generic case, localizers will have to work around the lack of information like they do today. There's no way to tell the gender of a person called "Andrea" or "Mic", or "Moon".

Going back to the three target audiences, the intent of this approach is to shield as much detail of a particular language from the application logic. Thus, no software author should ever see how many grammar variations the currently chosen language would have, all this information should be strictly encapsulated within the localization and the localization library. In addition, it is subject of the third group, people knowing internals of quite a bunch of languages, to create a set of properties and values to be used by applications to mark up for example the gender of an item.

Going back to the zero terms for this example, for a known finite set of values, even this odd-looking case can be handled.

Back to [[L20n]]...

[[category:L20n|Background]]

L20n/Background

2007-08-18T06:43:03Z

Jag: /* German sample */ Added in Butterblümchen sample

{{draft}}

When writing localizable software, in particular in an environment based on a toolkit, software authors and localizers are facing composited strings in the UI. Samples would be strings composited out of templates and computed data like in an address or a generic toolkit error message.

Localizers are facing three major challenges in this context:

# The string composition code includes assumptions on the grammar or composition of text.
# Different plural forms depending on a value.
# Different grammatical forms, depending on a given value.

The first item really just covers annoying bugs in the software, but they are way too common, and thus listed.

The second and third items are a tad more tricky, so let's make an example. It's based on two rather unfounded assumptions, firstly, that Jägermeister is such a gross drink that it would be of male gender anywhere in the world, and that daisies are cute enough to be female.

=== English sample ===
10 small Jägermeister hang around. 
9 small Jägermeister hang around. 
''... English is a bore ...'' 
1 small Jägermeister hangs around. 
Head off and order new ones!

The same with daisies:

10 small daisies hang around. 
''... well, yeah, dito ...'' 
1 small daisy hangs around. 
Head off and protect your environment!

Now for the same in German (which is still pretty darn simple)

=== German sample ===
10 kleine Jägermeister standen rum. 
''... German is a bore ...''
1 kleiner Jägermeister stand rum. 
Bestelle eine neue Runde!

10 kleine Butterblümchen standen rum. 
''... still ...'' 
1 kleines Butterblümchen stand run. 
Es ist Zeit für ein bisschen Umweltschutz!

Let's leave the zero value out for this discussion for the moment, because I really just entered fun values there. Let's assume that we're in the scenario of a generic toolkit message, and ''Jägermeister'' and ''daisy'' would be product specific. You could just as well think ''Firefox'' and ''Thunderbird''. Let's have two variables in this sample, ''name'' for ''Jägermeister'' or ''daisy'' and ''number'' for the values from 10 to 1.

For positive integers, gettext offers a reasonable approach, i.e., you have a macro that returns an index based on a number, and you use that to index an array. gettext does not offer a solution for the grammar and gender problems in this example, though.

For the given languages (and most languages, really), you need to know the gender of ''name'' to create the right composed string. In the common scenario that the value of ''name'' is actually in the localization data of your application, the localizer should know the gender. For other scenarios, there may be hints from the application for common requests like this. In a CRM application, for example, extracting the gender of a contact person shouldn't be the problem. In the generic case, localizers will have to work around the lack of information like they do today. There's no way to tell the gender of a person called "Andrea" or "Mic", or "Moon".

Going back to the three target audiences, the intent of this approach is to shield as much detail of a particular language from the application logic. Thus, no software author should ever see how many grammar variations the currently chosen language would have, all this information should be strictly encapsulated within the localization and the localization library. In addition, it is subject of the third group, people knowing internals of quite a bunch of languages, to create a set of properties and values to be used by applications to mark up for example the gender of an item.

Going back to the zero terms for this example, for a known finite set of values, even this odd-looking case can be handled.

Back to [[L20n]]...

[[category:L20n|Background]]

SeaMonkey:Scratchpad:Migration Announcement

2007-03-10T03:25:28Z

Jag: Fix typo, add more FIXMEs

The SeaMonkey team wants to get the word out publicly 1) that Mozilla suite users should upgrade and 2) that the SeaMonkey project exists and what it is.

We want to get this out to the press in all regions where we have our software available in local languages, which means that we're 1) asking our SeaMonkey L10n teams to localize this announcement and 2) asking peers in all local communities to send this out to the local press.

== Original (English, US) version ==

=== SeaMonkey project urges Mozilla users to upgrade ===

Two years after the end-of-line announcement for the Mozilla Application suite, 10 months after its last security update, and more than a year after the first release of its successor, the SeaMonkey team tries to win over people who are still using this Internet suite software.

"The Mozilla suite is outdated and insecure nowadays", said Robert Kaiser of the project-leading SeaMonkey Council, "In recent months the list of known security vulnerabilities has grown, but development has stopped on the Mozilla branded suite. There is a successor with the same browser/mail/composer/chat combination, improved functionality, and a steady flow of security updates - just under a different name: SeaMonkey."

The name change was needed to officially show that a group of dedicated volunteers had taken over development of the suite from Mozilla Foundation in March 2005. Mozilla Foundation is focusing on development of the stand-alone Firefox browser and Thunderbird mail clients, which it promotes as additional supported upgrade paths for users of the old Mozilla suite.

"With SeaMonkey we offer users of the Mozilla suite a way to stay with the more familiar suite style FIXME|<strike>instead of switching to differently working stand-alone applications</strike>|FIXME", said Robert Kaiser. "Downloads and more information can be found at www.seamonkey-project.org".

"Security threats on the Internet are constantly evolving, so it is important to use software that is actively being updated to address issues as they are discovered. FIXME|<strike>Additionally, choice and innovation are goals of the Mozilla community, and as members of that community, we offer those to Mozilla users through the SeaMonkey project</strike>|FIXME."

SeaMonkey is an Open-Source community project within the mozilla.org software family.

SeaMonkey:Scratchpad:Migration Announcement

2007-03-10T02:56:47Z

Jag: /* SeaMonkey project urges Mozilla users to upgrade */

The SeaMonkey team wants to get the word out publicly 1) that Mozilla suite users should upgrade and 2) that the SeaMonkey project exists and what it is.

We want to get this out to the press in all regions where we have our software available in local languages, which means that we're 1) asking our SeaMonkey L10n teams to localize this announcement and 2) asking peers in all local communities to send this out to the local press.

== Original (English, US) version ==

=== SeaMonkey project urges Mozilla users to upgrade ===

Two years after the end-of-line announcement for the Mozilla Application suite, 10 months after its last security update, and more than a year after the first release of its successor, the SeaMonkey team tries to win over people who are still using this Internet suite software.

"The Mozilla suite is outdated and insecure nowadays", tells Robert Kaiser of the project-leading SeaMonkey Council, "In recent months the list of known security vulnerabilities has grown, but development has stopped on the Mozilla branded suite. There is a successor with the same browser/mail/composer/chat combination, improved functionality, and a steady flow of security updates - just under a different name: SeaMonkey."

The name change was needed to officially show that a group of dedicated volunteers had taken over development of the suite from Mozilla Foundation in March 2005. Mozilla Foundation is focusing on development of the stand-alone Firefox browser and Thunderbird mail clients, which it promotes as additional supported upgrade paths for users of the old Mozilla suite.

"With SeaMonkey we offer the Mozilla suite users a way to stay with the more familiar suite style instead of switching to differently working stand-alone applications", says Robert Kaiser, pointing to www.seamonkey-project.org for detailed information and downloads.

"Security is very important on the Internet, so you should use software that is actively being updated to address security problems. Additionally, choice and innovation are goals of the Mozilla community, and as members of that community, we offer those to Mozilla users through the SeaMonkey project."

SeaMonkey is an Open-Source community project within the mozilla.org software family.

SeaMonkey:Scratchpad:Migration Announcement

2007-03-10T02:55:34Z

Jag: Changed wording here and there, hope this flows better.

The SeaMonkey team wants to get the word out publicly 1) that Mozilla suite users should upgrade and 2) that the SeaMonkey project exists and what it is.

We want to get this out to the press in all regions where we have our software available in local languages, which means that we're 1) asking our SeaMonkey L10n teams to localize this announcement and 2) asking peers in all local communities to send this out to the local press.

== Original (English, US) version ==

=== SeaMonkey project urges Mozilla users to upgrade ===

Two years after the end-of-line announcement for the Mozilla Application suite, 10 months after its last security update, and more than a year after the first release of its successor, the SeaMonkey team tries to win over people who are still using this Internet suite software.

"The Mozilla suite is outdated and insecure nowadays", tells Robert Kaiser of the project-leading SeaMonkey Council, "In recent months the list of known security vulnerabilities has grown, but development has stopped on the Mozilla branded suite. There is a successor with the same browser/mail/composer/chat combination, improved functionality, and a steady flow of security updates - just under a different name: SeaMonkey."

The name change was needed to officially show that a group of dedicated volunteers had taken over development of the suite from Mozilla Foundation in March 2005. Mozilla Foundation focuses on development of the stand-alone Firefox browser and Thunderbird mail clients, which it promotes as additional supported upgrade paths for users of the old Mozilla suite.

"With SeaMonkey we offer the Mozilla suite users a way to stay with the more familiar suite style instead of switching to differently working stand-alone applications", says Robert Kaiser, pointing to www.seamonkey-project.org for detailed information and downloads.

"Security is very important on the Internet, so you should use software that is actively being updated to address security problems. Additionally, choice and innovation are goals of the Mozilla community, and as members of that community, we offer those to Mozilla users through the SeaMonkey project."

SeaMonkey is an Open-Source community project within the mozilla.org software family.

Gecko

2005-06-29T06:19:15Z

Jag: Silly me.

#REDIRECT [[Gecko:Home_Page]]

Gecko

2005-06-29T06:18:11Z

Jag:

#REDIRECT [[http://wiki.mozilla.org/Gecko:Home_Page]]

RDF:API Rationale

2005-06-29T06:10:06Z

Jag:

Mozilla's RDF API has been architectured to follow the specs
[http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ RDF Model and Syntax 1999] and [http://www.w3.org/TR/1999/PR-rdf-schema-19990303/ RDF Schema 1999]. These specs are replaced with [http://www.w3.org/TR/rdf-primer/ RDF Primer 2004] and its five siblings. All of these are linked on [http://www.w3.org/ RDF W3C RDF].

On top of that, [https://bugzilla.mozilla.org/show_bug.cgi?id=122846 bug 122846] aims at exposing RDF to web content, which requires a thorough security review as well as a strict specifications of the APIs. Which are not given on the current APIs in Mozilla.

RDF:API Rationale

2005-06-29T06:06:46Z

Jag:

Mozilla's RDF API has been architectured to follow the specs
[http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ RDF Model and Syntax 1999] and [http://www.w3.org/TR/1999/PR-rdf-schema-19990303/ RDF Schema 1999]. These specs are replaced with [http://www.w3.org/TR/rdf-primer/ RDF Primer 2004] and its five siblings. All of these are linked on [http://www.w3.org/ RDF W3C RDF].

On top of that, [http://bugzilla.mozilla.org/show_bug.cgi?id=122846 bug 122846] aims at exposing RDF to web content, which requires a thorough security review as well as a strict specifications of the APIs. Which are not given on the current APIs in Mozilla.