5

Przechodzę do zadania i18n/l10n w dokumentacji dużego projektu. Dokumentacja jest wykonywana przy pomocy Sphinxa, który jest poza standardową wersją basic support for i18n.Czy można wygenerować pojedynczy plik .pot z dokumentacji Sphinx?

Mój problem jest podobny do tego z this other question: fakt, że duża część strun dla każdego pliku pot jest taka sama i chciałabym, aby moi tłumacze nie powtarzali tego samego tłumaczenia wielokrotnie. Wolałbym mieć jeden plik szablonu.

Mój problem nie polega na łączeniu plików (to tylko msgcat *.pot > all.pot), ale raczej na tym, że - aby domeny działały podczas tworzenia dokumentacji w danym języku - muszę skopiować i zmienić nazwę all.pot wróć do oryginalne nazwy plików. Więc moja workaroundish sposób pracy jest:

  1. Generowanie fileA.pot, fileB.pot
  2. Scalanie dwóch do all.pot
  3. cp all.pot fileA.pot + cp all.pot fileB.pot

Czy istnieje przejrzysty sposób zrobić to samo? gettext_compact przynosi mi tylko pół drogi przez mój cel ...

+0

Czy zastanawiałeś się nad użyciem pamięci tłumaczeniowej (która ma unikatowe wartości klucza/tłumaczenia)? – Shervin

+1

@Shervin - Tak, zrobiłem, ale to znacznie zwiększyłoby złożoność architektury, nie przynosząc żadnej korzyści wynikowi (ponad moje obecne obejście). – mac

Odpowiedz

1

Po ponad 7 miesiącach intensywnych badań i kilku próbach odpowiedzi, wydaje się bezpiecznie powiedzieć, że nie - przynajmniej z aktualną wersją 1.1.3 - nie można wygenerować pojedynczego pliku .pot z dokumentacji Sphinx.

Sposób postępowania opisany w pytaniu oryginalnym jest również najprostszy w przypadku automatycznego usuwania powtarzających się łańcuchów podczas łączenia różnych plików .pot w jeden.

0

widzę dwie możliwości tutaj:

jeden jest hack Sfinksa nie używać domen w ogóle ... co chyba nie będzie chciał zrobić dla kilka powodów.

Druga to: ponieważ dzielisz według domen, opcja -M z msggrep wygląda tak, jak robi to, co musisz zrobić. W przeciwnym razie opcja -N nadal może być używana do filtrowania według plików źródłowych.

To znaczy, jeśli oczywiste rozwiązanie nie działa:

  • generować fileA.pot, fileB.pot (również spojrzeć na msguniq tutaj)
  • połączyć je w all.pot i podać, że do tłumaczy
  • for x in file*.pot; do msgmerge -o ${x%t} all-translated.po $x; done

Według TFM, msgmerge trwa tylko (przypuszczalnie nowszych) tłumaczenia od pierwszego argumentu (przetłumaczony PO plik), które pasują do aktualnych lokalizacji źródłowych drugiego argumentu (plik po starych tłumaczeniach lub plik pot = szablon z tylko pustymi listami).

+0

Nie jestem pewien, czy mam przewagę techniczną tego rozwiązania, nad moim obecnym hackerem, czy mógłbyś wyjaśnić? – mac

+0

Zrozumiałem twój obecny hack, aby mieć wszystkie ciągi w ewentualnych plikach fileA.pot i fileB.pot i myślałem, że chcesz je wyczyścić. Jeśli tak nie jest, to obawiam się, że nie zrozumiałem twojego problemu poprawnie, czy możesz wyjaśnić, w jaki sposób możemy pomóc? – mirabilos

+0

Tytuł pytania mówi już wszystko. :) Ponadto twoja odpowiedź wydaje się powielać - na dłuższą metę - to, co rozwiązanie opisane w pytaniu już robi (spróbuj sam, wynik .pot jest już czysty i nie wymaga już żadnego mangowania) ... czy ja jestem czegoś brakuje? – mac

Powiązane problemy