'make' (or 'make all', if one is interested in the apidoc) should now
do everything needed to run from a git checkout. At the same time,
it no longer rebuilds all translations (xgettext run etc.). This
can be done with 'make translations'.
Using this method we're able to loop over the candidate directories
until we find what should be suitable AWL location. Further, adding
additional locations is as simple as adding a new line to ${awldirs}.
It does have the limitation that if the path has a new line in it
(/some/ridic
ulous/path), it'll treat it as two different paths. However, if
somebody seriously has that, they deserve the pain.
As proposed by 'mate' on IRC. This simple code hopefully also
demonstrates a good general starting point to future PHP scripts
running from the command-line within DAViCal.
We now build the dba/supported_locales.sql file from po/locale.values
files for each locale, and we are also fetching the translations from
transifex.net in order to build them.
This commit also adds support for some new locales, especially
Brazilian Portuguese and Mexican Spanish.
So far we have used extract.pl which originated in Horde to generate the
PO files. This process took a long time to run.
But xgettext is able to handle PHP by itself.
In the source translate() and i18n() are used instead of _() therefore
we have to pass a keyword parameter.
From now on Translators: is the keyword to provide content to the
translators on Transifex.
Conflicts:
scripts/po/extract.pl
This is kinda dodgy because AWL is external, so we expect it to
be unpacked in a parallel 'awl' directory. Otherwise we will not
change what is already coded into htdocs/always.php
It seems that on PUT Google might truncate the filename, so it will
send us back a Location header we need to follow before we can
getr the ETag. And there might be one more hoop to jump through
to complete this process.
This would be better handled if we locally use the VEVENT UID as
the invariant property between local and remote, rather than the
'filename' part of the path, but we'd still face the issue of
having to follow the Location: header to get the ETag for the
event we just PUT to the remote server.
