Hi all, Some news about the workflow. I attended the ESC meeting and the minutes of that part are below, discussion is still open. Coming back from Fosdem where Cloph, Alex, Florian and me met with Dwayne. It has been decided to put the new version on test by the end of the month, that should solve the performance issue and some other bugs. If you wish to participate to the test period, please rise your hand :)
* Translations problems (Sophie) + big chunk of translations for 4.4, to change our workflow to work on master instead of branches; so we can get visibility into that sooner and smooth the workload out. + 3x points on the dev. side. 1. ensure respect the en_US strings follow rules for sentance capitalization [ https://developer.gnome.org/hig-book/3.2/design-text-labels.html.en we re-use the GNOME HIG here ] saves thrash that hurts translators. 2. don't commit changes eg. appending '...' to menu items please discuss this with l10n before big-impact changes. + UX type thing (Kendy) + proposal from translators; make en_US a separate lang. touch the strings in the repo - as minimally as possible; + don't think this will work long-term; will need to improve what we have in the repo. + proposal is a tech. sol'n for a social problem. + for large-scale changes UX should talk to l10n first. + would be useful to have a l10n person in the UX call. + hopefully as/when everyone works on master, it is easy to see and have a tighter feedback cycle between the two teams. + UX & QA calls at the same time (Sophie) AI: + sort out the calls (Kendy / Sophie) 3. changes that affect all languages can be scripted + eg. _ in dialogs; could have been scripted; would like that tested on several languages + scripts should be applied out of pootle. Is there a way to do that ? (Caolan) + hackers see a git repo - which is a copy of what is in pootle + it'd be good to allow translators to see where the translations actually are. + either git is canonical, or have some well defined tooling to switch between. Is this a common problem now (Michael) + not particularly, but perhaps wrt. a gettext move (Caolan) + changing things wrt. a GNOME-HIG + putting a ':' at the end of labels. + discouraging. + what is the process of database (Michael) + DB -> po files -> script -> then files with changes checked -> git. (Cloph) + if we drop the format in the repo, could sync to & fro (Cloph) + with built-in pootle functionality; so pootle would allow commits directly to git + would create 100's of commits whenever pootle changes stuff + if translators use off-line .po files, would overwrite changes in the repo. + already the po files are multi-GB in size; the change-sets would be huge for replacements. + can't we do that for master (Markus) + and at feature-freeze throw away the old history + wonder if git is useful there (Thorsten) + is it an attempt to fix a social problem with a tech. problem. + scripting / changes in parallel are a problem (Stephan) + if that happens, we get conflicts -> always. + hold off for 2x weeks - while doing a change. + if we have a git repo where things are sneaked in underneath translators. + any big changes with a script, but can't be done with a technical protocol. + pootle on a branch, and a master repo ? (Bjoern) + wouldn't need a separate repo, but would need permissions from web interface (Cloph) + git repo easier to manage, + export pootle to a branch & merge them to master (Andras) + would need 2x repos, and directory layout not the same (Cloph) + can make it the same (Andras) Cheers Sophie -- Sophie Gautier sophie.gaut...@documentfoundation.org Tel:+33683901545 Co-founder - Release coordinator The Document Foundation -- To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/l10n/ All messages sent to this list will be publicly archived and cannot be deleted