/usr/share/pyshared/zope.i18nmessageid-3.5.3.egg-info/PKG-INFO is in python-zope.i18nmessageid 3.5.3-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 | Metadata-Version: 1.0
Name: zope.i18nmessageid
Version: 3.5.3
Summary: Message Identifiers for internationalization
Home-page: http://pypi.python.org/pypi/zope.i18nmessageid
Author: Zope Foundation and Contributors
Author-email: zope-dev@zope.org
License: ZPL 2.1
Description: To translate any text, we must be able to discover the source domain
of the text. A source domain is an identifier that identifies a
project that produces program source strings. Source strings occur as
literals in python programs, text in templates, and some text in XML
data. The project implies a source language and an application
context.
We can think of a source domain as a collection of messages and
associated translation strings.
We often need to create unicode strings that will be displayed by
separate views. The view cannot translate the string without knowing
its source domain. A string or unicode literal carries no domain
information, therefore we use messages. Messages are unicode strings
which carry a translation source domain and possibly a default
translation. They are created by a message factory. The message
factory is created by calling ``MessageFactory`` with the source
domain.
This package provides facilities for *declaring* such messages within
program source text; translation of the messages is the responsiblitiy
of the 'zope.i18n' package.
.. contents::
=============
I18n Messages
=============
Rationale
---------
To translate any text, we must be able to discover the source domain
of the text. A source domain is an identifier that identifies a
project that produces program source strings. Source strings occur as
literals in python programs, text in templates, and some text in XML
data. The project implies a source language and an application
context.
We can think of a source domain as a collection of messages and
associated translation strings.
We often need to create unicode strings that will be displayed by
separate views. The view cannot translate the string without knowing
its source domain. A string or unicode literal carries no domain
information, therefore we use messages. Messages are unicode strings
which carry a translation source domain and possibly a default
translation. They are created by a message factory. The message
factory is created by calling ``MessageFactory`` with the source
domain.
ZopeMessageFactory
------------------
>>> from zope.i18nmessageid import ZopeMessageFactory as _z_
>>> foo = _z_('foo')
>>> foo.domain
'zope'
Example
-------
In this example, we create a message factory and assign it to _. By
convention, we use _ as the name of our factory to be compatible with
translatable string extraction tools such as xgettext. We then call _
with a string that needs to be translatable:
>>> from zope.i18nmessageid import MessageFactory, Message
>>> _ = MessageFactory("futurama")
>>> robot = _(u"robot-message", u"${name} is a robot.")
Messages at first seem like they are unicode strings:
>>> robot
u'robot-message'
>>> isinstance(robot, unicode)
True
The additional domain, default and mapping information is available
through attributes:
>>> robot.default
u'${name} is a robot.'
>>> robot.mapping
>>> robot.domain
'futurama'
The message's attributes are considered part of the immutable message
object. They cannot be changed once the message id is created:
>>> robot.domain = "planetexpress"
Traceback (most recent call last):
...
TypeError: readonly attribute
>>> robot.default = u"${name} is not a robot."
Traceback (most recent call last):
...
TypeError: readonly attribute
>>> robot.mapping = {u'name': u'Bender'}
Traceback (most recent call last):
...
TypeError: readonly attribute
If you need to change their information, you'll have to make a new
message id object:
>>> new_robot = Message(robot, mapping={u'name': u'Bender'})
>>> new_robot
u'robot-message'
>>> new_robot.domain
'futurama'
>>> new_robot.default
u'${name} is a robot.'
>>> new_robot.mapping
{u'name': u'Bender'}
Last but not least, messages are reduceable for pickling:
>>> callable, args = new_robot.__reduce__()
>>> callable is Message
True
>>> args
(u'robot-message', 'futurama', u'${name} is a robot.', {u'name': u'Bender'})
>>> fembot = Message(u'fembot')
>>> callable, args = fembot.__reduce__()
>>> callable is Message
True
>>> args
(u'fembot', None, None, None)
Message IDs and backward compatability
--------------------------------------
The change to immutability is not a simple refactoring that can be
coped with backward compatible APIs--it is a change in semantics.
Because immutability is one of those "you either have it or you don't"
things (like pregnancy or death), we will not be able to support both
in one implementation.
The proposed solution for backward compatability is to support both
implementations in parallel, deprecating the mutable one. A separate
factory, ``MessageFactory``, instantiates immutable messages, while
the deprecated old one continues to work like before.
The roadmap to immutable-only message ids is proposed as follows:
Zope 3.1: Immutable message ids are introduced. Security
declarations for mutable message ids are provided to make the
stripping of security proxies unnecessary.
Zope 3.2: Mutable message ids are deprecated.
Zope 3.3: Mutable message ids are removed.
=======
CHANGES
=======
3.5.3 (2010-08-10)
------------------
- Made compilation of C extension optional again; 3.5.1 broke this
inasmuch as this package become unusable on non-CPython platforms.
Making the compilation of the C extension optional again implied
removing ``setup.py`` code added in 3.5.1 which made the C extension
a setuptools "Feature" and readding code from 3.5.0 which overrides
the distutils ``build_ext`` command.
- Move pickle equality tests into a unittest.TestCase test to make it
easier to condition the tests on whether the C extension has been
compiled. This also makes the tests pass on Jython.
3.5.2 (2010-04-30)
------------------
- Removed use of 'zope.testing.doctestunit' in favor of stdlib's 'doctest.
3.5.1 (2010-04-10)
------------------
- LP #257657 / 489529: Fix memory leak in C extension.
- Fixed the compilation of the C extension with python 2.6: refactored it as a
setuptools Feature.
3.5.0 (2009-06-27)
------------------
- Made compilation of C extension optional.
- Added support to bootstrap on Jython.
- Changed package's mailing list address from zope3-dev at zope.org to
zope-dev at zope.org, because zope3-dev is now retired.
- Reformatted change log to common formatting style.
- Update package description and docs a little.
- Remove old .cfg files for zpkg.
3.4.3 (2007-09-26)
------------------
- Make PyPI the home URL.
3.4.2 (2007-09-25)
------------------
- Moved the ``ZopeMessageFactory`` from ``zope.app.i18n`` to this package.
3.4.0 (2007-07-19)
------------------
- Remove incorrect dependency.
- Create final release to reflect package status.
3.2.0 (2006-01-05)
------------------
- Corresponds to the verison of the zope.i18nmessageid package shipped as
part of the Zope 3.2.0 release.
- Implemented 'zope.i18nmessageid.message' as a C extension.
- Deprecated 'zope.i18nmessageid.messageid' APIs ('MessageID',
'MessageIDFactory') in favor of replacements in 'zope.i18nmessageid.message'
('Message', 'MessageFactory'). Deprecated items are scheduled for removal
in Zope 3.3.
3.0.0 (2004-11-07)
------------------
- Corresponds to the verison of the zope.i18nmessageid package shipped as
part of the Zope X3.0.0 release.
Keywords: zope i18n message factory
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Environment :: Web Environment
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: Zope Public License
Classifier: Programming Language :: Python
Classifier: Natural Language :: English
Classifier: Operating System :: OS Independent
Classifier: Topic :: Internet :: WWW/HTTP
Classifier: Framework :: Zope3
|