Home | Trees | Indices | Help |
---|
|
object --+ | monitored.Monitored --+ | Catalog
Class for access and operations on PO catalogs.
Catalog behaves as an ordered sequence of messages. The typical way of iterating over the messages from a PO file on disk would be:
cat = Catalog("relative/path/foo.po") for msg in cat: ... (do something with msg) ... cat.sync()
where sync() method is used to write any modifications back to the disk.
The header entry of the catalog is not part of the message sequence, but is provided by the header attribute, an object of type different from an ordinary message entry.
The catalog is a monitored class. Catalog message entries themeselves may also be monitored (default), but need not, depending on the mode of creation.
Instance Methods | |||
|
|||
|
|||
int |
|
||
Message_base |
|
||
Message_base |
|
||
bool |
|
||
bool |
|
||
bool |
|
||
int |
|
||
Message_base or type(defmsg) |
|
||
int or None |
|
||
[int or None, ...] |
|
||
int |
|
||
|
|||
|
|||
|
|||
bool |
|
||
|
|||
int, float |
|
||
bool |
|
||
int |
|
||
int |
|
||
[int*] |
|
||
[Message_base*] |
|
||
[Message_base*] |
|
||
[Message_base*] |
|
||
[Message_base*] |
|
||
[Message_base*] |
|
||
string |
|
||
|
|||
set(string*) or None
|
|
||
|
|||
set(string*) or None
|
|
||
|
|||
string or None
|
|
||
|
|||
[string*] or None
|
|
||
|
|||
(string...) or None
|
|
||
|
|||
(string, string, string?)->[string] |
|
||
[(string, [Message_base])] |
|
||
|
|||
|
|||
{string: [string*]*} |
|
||
Inherited from Inherited from |
Instance Variables | |
string |
filename the file name which the catalog was created with |
Header |
header the header entry |
string |
name (read-only) the name of the catalog |
Properties | |
Inherited from |
Method Details |
Build a message catalog by reading from a PO file or creating anew. The message entries in the catalog may be monitored themselves or not. That is, when monitoring is requested, entries are represented by the Message class, otherwise with MessageUnsafe. Monitored messages are usually appropriate when the application is expected to modify them. Non-monitored messages should provide better performance, so use them whenever the catalog is opened for read-only purposes (such as checks). Catalog can also be opened in header-only mode, for better performance when only the header data is needed. This mode provides header attribute as usual, but the rest of entries are unavailable. If any of the operations dealing with message entries are invoked, an error is signaled. Instead of opening and reading from catalog's filename, catalog can be
read from a file-like object provided by If a problem which prevents construction of a valid catalog is detected while parsing a PO file, CatalogSyntaxError is raised.
|
Attribute getter. Processes read-only attributes, and sends others to the base class.
|
The number of messages in the catalog. The number includes obsolete entries, and excludes header entry.
|
Get message by position or another message. If the position is out of range, or the lookup message does not have a counterpart in this catalog with the same key, an error is signaled. Runtime complexity O(1), regardless of the
|
Set message by position or another message. If the position is out of range, or the lookup message does not have a counterpart in this catalog with the same key, an error is signaled. Runtime complexity O(1), regardless of the
|
Whether the message with the same key exists in the catalog. Runtime complexity O(1).
|
Whether two catalogs are equal in all apparent parts. Catalogs are considered equal if they are of the same length, their headers are equal, and each two messages with the same position are equal. Runtime complexity O(n).
|
Whether two catalogs are equal in all apparent parts. Equivalent to
|
Position of the message in the catalog. Runtime complexity O(1).
|
Get message by key of another message, with default fallback. If the lookup message Runtime complexity O(1).
|
Add a message to the catalog. If the message with the same key already exists in the catalog, it
will be replaced with the new message, ignoring position. The return
value will be If the message does not exist in the catalog, when the position is
Negative position can be given as well. It counts backward from the first non-obsolete message if the message to be added is not obsolete, or from last message otherwise. When the message is inserted according to source references, a
dictionary of file paths to consider synonymous can be given by the
Runtime complexity O(1) if the message is present in the catalog; O(n - pos) if the position is given and the message is not present; O(n) if the position is not given and the message is not present.
|
Add more than one message to the catalog. Like add, except that several messages are added in one call. This significantly speeds up insertion when insertion positions of all messages are known beforehand. Insertion positions can be given relative to state before the call, or
cumulative to earlier insertions in the list. For example, if insertions
are given as
|
Get canonical position of the first obsolete message. Canonical position of the first obsolete message is the position of first of the contiguous obsolete messages at the end of the catalog. Normally this should be the same as the position of the very first obsolete message, as all obsolete messages should be contiguously grouped at the end. But there is no enforcement of such grouping, therefore the more stricter definition. If there are no messages in the catalog, or the last message is not obsolete, the position is reported as number of messages (i.e. one position after the last message). Runtime complexity O(number of contiguous trailing obsolete messages).
|
Add a message to the selected end of catalog, if not already in it. Synonym to See Also: add |
Remove a message from the catalog, by position or another message. If the position is out of range, or the lookup message does not have a counterpart in this catalog with the same key, an error is signaled. Runtime complexity O(n), regardless of
|
Remove a message from the catalog, by position or another message, on the next sync. If the position is out of range, or the lookup message does not have a counterpart in this catalog with the same key, an error is signaled. Suited for for-in iterations over a catalog with a sync afterwards, so that the indices are not confused by removal, and good performance. Runtime complexity O(1).
|
Write catalog file to disk if any message has been modified. All activities scheduled for sync-time are performed, such as delayed message removal. If catalog is monitored, unmodified messages (and message parts) are not reformatted unless forced. Instead of opening and writing into catalog's filename, catalog can be
written to a file-like object provided by
|
Update message map. In case there were any modifications to message keys, or any pending removals issued, this function will update the sequence of messages such that membership operations work properly again. Obsolete messages will be moved to end of catalog. Referent line and entry numbers will remain invalid, as catalog will not be written out. This is a less expensive alternative to syncing the catalog, when it is only necessary to continue using it in synced state, rather than actually writing it out. |
Compute the tentative insertion of the message into the catalog. The tentative insertion is a tuple of position of a message when it would be inserted into the catalog, and the weight indicating the quality of positioning. The weight is computed by analyzing the source references. Runtime complexity O(n).
|
Whether the catalog has been newly created (no existing PO file). A catalog is no longer considered newly created after the first sync.
|
Number of msgstr fields expected for plural messages. Determined by the Plural-Forms header field; if this field is absent from the header, defaults to 1.
|
Msgstr field index in plural messages for given number. Determined by the Plural-Forms header field; if this field is absent from the header, defaults to 0.
|
Indices of the msgstr fields which are used for single number only.
|
Select message from the catalog by the fields that define its key. If matched, the message is returned as a single-element list, or an
empty list when there is no match. This is so that the result of this
method is in line with other Runtime complexity as that of find.
|
Select messages from the catalog by matching key-defining fields. Parameters Runtime complexity O(n), unless all matches are exact, when as that of find.
|
Select messages from the catalog by matching Several messages may have the same Runtime complexity O(n).
|
Select messages from the catalog by near-matching The The messages are returned ordered by decreasing similarity. Runtime complexity O(n) * O(length(msgid)*avg(length(msgids))) (probably).
|
Select messages from the catalog inversely, by their msgstr[0]. Several messages may have the same Runtime complexity is O(n) if
|
Report encoding used when syncing the catalog. Encoding is determined from It is not defined when the header will be examined, or if it will be reexamined when it changes. If you want to set encoding after the catalog has been opened, use set_encoding.
|
Set encoding used when syncing the catalog. Encoding set by this method will later be readable by the encoding method. This will also modify the catalog
header
|
Report characters used as accelerator markers in GUI messages. Accelerator characters are determined by looking for certain header
fields, in this order: If empty set is returned, it was determined that there are no
accelerator markers in the catalog; if It is not defined when the header will be examined, or if it will be reexamined when it changes. If you want to set accelerator markers after the catalog has been opened, use set_accelerator.
|
Set accelerator markers that can be expected in messages. Accelerator markers set by this method will later be readable by the accelerator method. This will not modify the catalog header in any way; if that is desired, it must be done manually by manipulating the header fields. If
|
Report what types of markup can be expected in messages. Markup types are determined by looking for some header fields, which
state markup types as short symbolic names, e.g. "html",
"docbook", "mediawiki", etc. The header fields are
tried in this order: If empty set is returned, it was determined that there is no markup in
the catalog; if It is not defined when the header will be examined, or if it will be reexamined when it changes. If you want to set markup types after the catalog has been opened, use set_markup method.
|
Set markup types that can be expected in messages. Markup types set by this method will later be readable by the markup method. This will not modify the catalog header in any way; if that is desired, it must be done manually by manipulating the header fields. If The following markup types are currently used by various parts of Pology to influence behavior on processing:
|
Report language of the translation. Language is determined by looking for the It is not defined when the header will be examined, or if it will be reexamined when it changes (most probably not). If you want to set language after the catalog has been opened, use set_language method.
|
Set language of the translation. Language set by this method will later be readable by the language method. This will not modify the catalog header in any way; if that is desired, it must be done manually by manipulating the header fields. If
|
Report environments which the catalog is part of. Sometimes the language alone is not enough to determine all the non-technical aspects of translation. For example, in a given language but different translation domains, one translator may decide to use one of the two synonyms naming a concept, and the other translator the other synonym. Environments are a way to specify such sets of choices, so that automatic tools (e.g. terminology checker) can detect how to process a given catalog. An environment can represent anything. It may be a single translator, who applies own set of choices to all the catalogs under own maintenance; it may be a translation project, with many cooperating translators; and so on. Each environment is named by an alphanumeric keyword (such as normalized project name, translator's name, etc.), and should be unique within a given language. Environments are read from one of the following header fields:
If more than one environment is stated, then wherever the conventions
of two environments conflict, the environment mentioned later in the list
should take precedence. For example, environment list such as
It there is no environment header field, It is not defined when the header will be examined, or if it will be reexamined when it changes (most probably not). if you want to set environments after the catalog has been opened, use set_environment method.
|
Set environments which the catalog is part of. Environments set by this method will later be readable by the environment method. This will not modify the catalog header in any way; if that is desired, it must be done manually by manipulating the header fields. If
|
Report wrapping policy for message fields. Long text fields in messages ( The following header fields are checked for wrapping policy, in given
order: It is not defined when the header will be examined, or if it will be reexamined when it changes (most probably not). If you want to set wrapping after the catalog has been opened, use set_wrapping method.
|
Set wrapping policy for message fields. Wrapping policy set by this method will later be readable by the wrapping method. This will not modify the catalog header in any way; if that is desired, it must be done manually by manipulating the header fields. Wrapping policy is a sequence of keywords. See select_field_wrapper for possible keywords. If
|
Get wrapping function used for message fields. Wrapping function is determined based on wrapping policy (see wrapping, set_wrapping). Wrapping function returned by this method
is suitable as
See Also: wrap_field |
Get messages grouped as lists by source. All messages sharing the same primary source file (their first source reference) are grouped and filed under that source file path. Grouping is represented by list of tuples of (source, list of messages), with both sources and messages within partial lists ordered by appearance.
|
Sort messages in catalog by source references. Source references within each message are sorted too, before messages are sorted by source references. If any message changed its position due to sorting, sync_map is called at the end. |
Update catalog header. If a piece of information is not given (i.e. Some fields (as noted in parameter descriptions) are expanded on variables by applying the expand_vars function. For example: title="Translation of %project into %langname." The following variables are available:
|
Heuristically determine possible renamings of source files from this catalog based on source files in the other catalog. To determine the possibility that the source file A from this catalog
has been renamed into source file B in the other catalog
When a source file from this catalog is directly mentioned in the other catalog, it is immediatelly considered to have no possible renamings. The return value is a dictionary in which the key is the source file and the value is the list of its possible renamed counterparts. The renaming list is never empty, i.e. if no renamings were detected for a given source file, that source file will not be present in the dictionary. The dictionary is fully symmetric: if source file B is in the renaming list of file A, then there will be an entry for file B with A in its renaming list (even when B is comming from the other catalog). Instead of a single other catalog to test against, a sequence of several other catalogs can be given.
|
Instance Variable Details |
name(read-only) the name of the catalogDetermined as base of the filename, without extension.
|
Home | Trees | Indices | Help |
---|
Generated by Epydoc 3.0.1 on Thu Jul 24 21:00:27 2014 | http://epydoc.sourceforge.net |