Hallo Jens,
On Thu, May 22, 2008 at 12:04:39PM +0200, Jens Seidel wrote:
> On Thu, May 22, 2008 at 08:30:14AM +0200, Helge Kreutzmann wrote:
> Zum zweiten Punkt: ja. -unchecked entspricht der bisherigen
> Übersetzungsdatei (ist nur etwas kürzer, da Pakete in -checked dort
> nicht auftreten müssen/sollten). Die Synchronisation von -checked mit
> den Entbenutzern bleibt noch zu klären. Vielleicht könnten wir sogar
> einen eigenen Mirror bereitstellen (ohne *.deb-Pakete).
Ok, wichtig ist, dass dann von unserer Seite die Apt-Quellen und
p.d.o. gespeist würden.
> Ich würde die aktuelle Translation-de vom DDTP-Server mit der Version
> vom Vortag vergleichen (per cron-Job) und alle geänderten Pakete zu
> -unchecked hinzufügen (bzw. dort ersetzen falls schon vorhanden). Damit
> ist diese Datei nicht allzu groß.
>
> Ein Nachteil deiner Methode, mit Kommentaren immer (statt nur anfangs)
> festzulegen, ob eine Übersetzung überprüft wurde oder nicht, ist, dass
> dies komplizierter ist, da man nicht einfach zur nächsten nicht korrigierten
> Version springen kann bzw. Suchvorgänge (zur Vereinheitlichung von
> Übersetzungen, Stils) alle Beschreibungen erfassen würden.
Ich glaube, Du bringst da etwas durcheinander. Meine Vorschlage
betrifft das Analogon zum (Fehlen der) »fuzzy«-Markierung. Die Frage
der globalen Suche ist der Vorschlag von Thomas, für jede
Paketbeschreibung eine eigene Datei zu verwenden.
Zum ersteren: Wenn wir manuell von -unchecked auf -checked kopieren,
dann entspricht das (kombiniert mit dem RCS-Protokoll) ja einer
Freigabe, die Kommentierung könnte »im Betrieb« entfallen.
Zum zweiten: Siehe die Diskussion früher in diesem Strang, Thomas
brachte Argumente für einzelne Dateien und dem Umgang mit vergleichen.
> Jedoch könnten wir dies Schema *anfangs* in -checked verwenden, falls wir
> diese Datei mit Translation-de initialisieren sollten (was ich
> vorschlage). Auf diese Weise könnten wir manuell vorgeben, ob eine
> Beschreibung schon korrekturgelesen wurde oder nicht (also Standard-Tag:
> "# unchecked (from old file)", beim Korrekturlesen wird dies nach und
Das ist vernünftig, weil wir ansonsten Probleme beim kopieren bekommen
könnten. Ev. sollten wir die Initialisierungsphase hier grob manuell
unterstützen (»ich kümmere mich bis Samstag um alle Übersetzungen von
a bis ...«), damit das RCS da keine Problem mehr hat. Im späteren
Wirkbetrieb sehe ich da dann keine Probleme mehr, eher das wir da auch
regelmäßig hineinschauen.
> nach entfernt). Da ich aber davon ausgehe, dass mehr als 50% der alten
> Beschreibungen in Ordnung sind, sollten diese anfangs einfach übernommen
> werden. Alle komplett unsinnigen Übersetzungen können schnell manuell
> aus -checked entfernt werden, so dass sie am nächsten Tag automatisch in
> -unchecked auftauchen.
Naja, Korrekturlesen bedeutet auch den Vergleich mit dem Original, so
dass ich mir über das »einfach übernommen« nicht so sicher bin.
> Sollten uns Patches geschickt werden, muss nur der -checked-Teil von
> denjenigen mit Schreibrechten überprüft werden, -unchecked ist
> bedeutungslos (im schlimmsten Fall würde eine Beschreibung dort nicht
> herausgelöscht werden, was später eine weitere Korrektur bedeuten würde).
I.o., wobei für alle interessierten die primäre Schnittstelle wohl
weiter die bisherigen blieben, oder? Nur das Freigabe-Team würde
i.d.R. direkt auf den Dateien arbeiten, oder?
> > verwenden, nicht für den Wirkbetrieb. Kannst Du auf Alioth ein neues
> > Projekt erstellen?
>
> Ja, mache ich (aber für alle Sprachen, so dass andere Sprachteams
> beitreten können, wenn sie es wollen)!
Dann solltest Du es aber auch kurz auf debian-i18n vorstellen. Die
konkreten Skripte können die anderen Sprachen (die beitreten wollen)
ja variieren, das Depot ist ja mehr ein gemeinsamer Lager-/Umschlageplatz
der Daten.
Viele Grüße
Helge
--
Dr. Helge Kreutzmann helge@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature