Localize BOF Friday sep 4 2009
Projects on d.o -> releases -> localize.d.o -> parse files -> grab t()'s -> translate
Drupal site -> t()'s -> translate -> back to l.d.o?
CVS or no?
Translators aren't CVS tecky
Current workflow doesn't work for contrib, because if we grab the translations when a project is packaged, it's technically too late.
Installing core translations is too tedious on "most" systems, because you have to copy the po files with the folders over the core, and some systems then replace the entire folder. possible solution would be to package everything in 1 big po file and possibly compressing it, which would make Gzip a requirement.
Releases or snapshots? do we wait for translation maintainers to push a release, or do we take an occassional snapshot?
for core -> Releases
for contrib -> Snapshots (once a week?)
now... what to do when a module has a new release?
keep the latest snapshot per branch and keep one for the previous version, but mark it as "unsupported" or something
How to go about having Drupal automatically grab the latest translation for core on install, as must people have internet when they are installing Drupal?
And how do we make this easily overridable? hook_po_edit()? :P
There is currently a patch in the D7 queue to be able to alter the default language during install...
And if we make Drupal automatically fetch the translation upon installation, how do we go about updates? contrib?
Currently for contrib, if an English user who will only use English downloads a module, he will still get the po files for every language the module was translated to... this shouldn't be that way, because providing all languages to everyone doesn't make sense
It's a lot better to offer separate languages in a similar structure as the modules are, so this comes down to 1 file per language per release per week
Currently, the history is already being kept in the database on l.d.o, so we only put the latest version in a physical file
So we have about 2 days to change the install to create the tmp files directory earlier on, so we can download a list of languages, let the user choose, then grab the install translation for that language, parse it from the file like we do now, and once we have a database and a list of installed modules that came with the profile, we can then download the big po files for everything and parse it all and stuff it in the database.
