[kde-doc-english] License translation cleanup in KDocTools, help needed
Burkhard L?ck ha scritto: Am Mittwoch, 16. April 2014, 01:51:42 schrieb Luigi Toscano: - css files for each language. Basically all the css files are empty (apart from one role in the romanian one) Afar we has already a mail thread about the usage of these language css files (in kde-i18n-doc or kde-doc-english), but I can not find this thread anymore. Oh, this one? http://lists.kde.org/?l=kde-i18n-docm=124896979211881w=2 The problem comes from the translation of the licenses. I see two ways to deal with them: - copy the existing files from SVN with the history. I had a look at the german files and doubt we need the history here, it is mostly just one commit for a file. Pros: I'm the only one who needs to do something. Cons: I need help with the SVN-git conversion rules; need to fix the encoding issues; some translations could be outdated or need some tuning (some of them seems to miss the headers this is an unofficial translation etc). - leave a basic css file and nothing else, let translators put the files if they think it's worth. Pros: less work from me (especially the conversion rules) :), cleanup Cons: more work on you From my experience with mails about obsolete docbooks some teams will do nothing here. Yep :( What do you think about this? If you think it does not make sense to start over, I will invest some time for a proper migration (with history). Copy without history to kdoctools is sufficient, I guess that would most teams do themselves. My only concern is for proper credits. Maybe I could just copy them and add the credits in the commit message. What do you think? Anyway, I need to fix the encoding issues before (iconv should help) Ciao -- Luigi
[kde-doc-english] License translation cleanup in KDocTools, help needed
Dear all, this is a long email but I can't really summarize it more, sorry for that. I'm planning another change in KDocTools but I need your input. Right now (kdelibs4 world, but also before) some common files are installed under $HTML_INSTALL_DIR/lang/common which usually means /usr/share/doc/HTML/lang/common or /usr/share/kde4/doc/HTML/lang/common There is a bit of inconsistency here: the content of en/ language is shipped and installed by kdelibs; the content for any other language is available in our SVN, under trunk/l10n-kde4/lang/docs/common. What is the content of those directories? The content is used for URLs like help:/common/filename in documentation. - css files for each language. Basically all the css files are empty (apart from one role in the romanian one) - translation of common license, GPL, LGPL and FDL. Many translations seems to miss the this is only an official translation header, though. * As you probably know documentation handling is in the KDocTools in the Frameworks 5 world, and I would like to do some cleaning. In more details: - move those files (if really used) inside kdoctools, - install them from kdoctools in $HTML_INSTALL_DIR/lang/kdoctools-common - remove the lang/docs/common directories from SVN: we already ship many translated entities there (please recheck my previous mail about this, maybe you have to fix some strings :) and the content does not change so much anyway. - add back those contents, and here is big question for you about the deal with the import! The css files will be created from scratch, empty. The problem comes from the translation of the licenses. I see two ways to deal with them: - copy the existing files from SVN with the history. Pros: I'm the only one who needs to do something. Cons: I need help with the SVN-git conversion rules; need to fix the encoding issues; some translations could be outdated or need some tuning (some of them seems to miss the headers this is an unofficial translation etc). - leave a basic css file and nothing else, let translators put the files if they think it's worth. Pros: less work from me (especially the conversion rules) :), cleanup Cons: more work on you What do you think about this? If you think it does not make sense to start over, I will invest some time for a proper migration (with history). As a final note, here is the list of currently translated license files with some notes: fdl-translated.html: de, eu, hu (*), ko (*), nl (*), uk; gpl-translated.html: de, el (*, French version(!)), eu, fr (*), hu (*), it (*), ko (*), nl (header only), pt_BR, pl (*), sl, tr (*), uk, zh_TW (*); lgpl-translated: hu, nl (headers only), pt_BR, sl, uk, zh_TW(*); (*) means encoding issues Ciao -- Luigi
[kde-doc-english] License translation cleanup in KDocTools, help needed
Am Mittwoch, 16. April 2014, 01:51:42 schrieb Luigi Toscano: Dear all, this is a long email but I can't really summarize it more, sorry for that. I'm planning another change in KDocTools but I need your input. Right now (kdelibs4 world, but also before) some common files are installed under $HTML_INSTALL_DIR/lang/common which usually means /usr/share/doc/HTML/lang/common or /usr/share/kde4/doc/HTML/lang/common There is a bit of inconsistency here: the content of en/ language is shipped and installed by kdelibs; the content for any other language is available in our SVN, under trunk/l10n-kde4/lang/docs/common. What is the content of those directories? The content is used for URLs like help:/common/filename in documentation. - css files for each language. Basically all the css files are empty (apart from one role in the romanian one) Afar we has already a mail thread about the usage of these language css files (in kde-i18n-doc or kde-doc-english), but I can not find this thread anymore. - translation of common license, GPL, LGPL and FDL. Many translations seems to miss the this is only an official translation header, though. * As you probably know documentation handling is in the KDocTools in the Frameworks 5 world, and I would like to do some cleaning. In more details: - move those files (if really used) inside kdoctools, - install them from kdoctools in $HTML_INSTALL_DIR/lang/kdoctools-common - remove the lang/docs/common directories from SVN: we already ship many translated entities there (please recheck my previous mail about this, maybe you have to fix some strings :) and the content does not change so much anyway. - add back those contents, and here is big question for you about the deal with the import! The css files will be created from scratch, empty. The problem comes from the translation of the licenses. I see two ways to deal with them: - copy the existing files from SVN with the history. I had a look at the german files and doubt we need the history here, it is mostly just one commit for a file. Pros: I'm the only one who needs to do something. Cons: I need help with the SVN-git conversion rules; need to fix the encoding issues; some translations could be outdated or need some tuning (some of them seems to miss the headers this is an unofficial translation etc). - leave a basic css file and nothing else, let translators put the files if they think it's worth. Pros: less work from me (especially the conversion rules) :), cleanup Cons: more work on you From my experience with mails about obsolete docbooks some teams will do nothing here. What do you think about this? If you think it does not make sense to start over, I will invest some time for a proper migration (with history). Copy without history to kdoctools is sufficient, I guess that would most teams do themselves. As a final note, here is the list of currently translated license files with some notes: fdl-translated.html: de, eu, hu (*), ko (*), nl (*), uk; gpl-translated.html: de, el (*, French version(!)), eu, fr (*), hu (*), it (*), ko (*), nl (header only), pt_BR, pl (*), sl, tr (*), uk, zh_TW (*); lgpl-translated: hu, nl (headers only), pt_BR, sl, uk, zh_TW(*); (*) means encoding issues Thanks -- Burkhard L?ck
