TODO

Support a custom column wrap value. If you interact with services that wrap
differently than a2po (like transifex, does not wrap at all), diffs will
be unnecessarily large.

If an expport op does not change a .po file, it's modified date should NOT
change.

Android does not support ISO 639-2 three-letter language codes; ignore those
rather than generating invalid Android resource directories.

The --verbose option currently doesn't do a lot. We could output more
diagnostics, for example if and how many strings were ignored etc.

Validate format strings on import.

I'd like to reorganize the test suite: Separate tests into
  a) how text is parsed (format/escaping-wise)
  b) which strings are parsed (given the different options)
  c) how high-level input/output is handled (template name etc).

An option to not process comments probably makes sense. If people don't
pay attention to the rules with how comments are applied, the result can
be confusing comments on the wrong strings.

The --ignore option could be supported through additional venues: A .po
file that includes the strings to be ignored. Also, strings that
should be ignored could be marked directly in the xml via a special
attribute in a custom android2po namespace.

Our array support currently has trouble with a particular use case: If
the array is not supposed to be fixed-length, but rather serves as a
collection of strings, the number of which may differ from language
to language. Granted, there isn't really a good way to map this to
.po anyhow, except maybe a single field that needs to use some kind of
separator. Not sure if this is something worth supporting.

Add some kind of variation on the init command that would automatically
install a config file if it doesn't exist. Maybe we could to this if init
is called without any .po files existing yet, and without a specific
language being requested.

Options we would like to support:
    - ability to pull .po header fields into messages
    - option to emulate "always quote" mode, emulating the behavior of what
      seems to be an converter Google uses internally, which quotes all
      strings, regardless if they contain any content that would benefit
      from quoting.

There are some areas of code that we currently don't test; mostly the
basic environment handling (detecting config file etc). Also, coverage
reports indicate that the export command is largly untested.

We would like to support comments in the XML file that can be used to
pass along information for the translator.

Support "values-en-rUS-finger"-style resource directories. We could do
this by adding a comment to each string indicating the source directory
and/or file (allowing us to handle files like, say, arrays.xml as well).
"import" can then use those comments to properly restore the strings in
the correct locations.

More explicitly handle empty strings, like print a warning that they
will not be included on export; on import, we might want to include
them. We could also put in warning comments in the generated file as
the tool Google users internally seems to do, e.g. something like:
 <!-- translation not found: %resource-name% -->

Check our xliff namespace support with respect to whitespace handling:
localized XML of Android's own apps, which are clearly generated by a tool,
use "..." to wrap around the total string, including the xliff tags, while
for strings that contain normal html tags it uses the same approach as we
do - wrapping around each block of text between the tags (see the Browser
app for an example). Why is that?

It would be cool if we could use comments and custom headers to store
data help dealing with certain things like xml namespaces. I'm afraid
though that too many tools cause those to be lost. Investigate.

Android's Settings app uses <skip /> tags in it's language-specific XML
string files. Find out what that means, and if we need to support it.