On 30.08.2017 12:51, Leandro Regueiro wrote:
On Wed, Aug 30, 2017 at 12:09 PM, Sveinn í Felli <sv1@fellsnet.is> wrote:Þann mið 30.ágú 2017 09:14, skrifaði Martin Srebotnjak:So, these changes will make 100+ l10n teams to re-translate/check those touched strings, yes?Well, these have been brewing for some time; think we have to live with that. But of course we should make noise if there is a bunch of such 'cosmetic' modifications, all at once. Meanwhile, we could think seriously about why the help/docs markup is so complex (instead of being more CSS-like?) and why there's so little separation of content and formatting - and what can be done???I would also add why strings have so many tags when the only translatable content is outside of the tags or in a single place in the string, like: <image src="cmd/sc_compilebasic.png" id="img_id3147576"><alt id="alt_id3147576">Icon</alt></image> We have tons of strings like this where the only translatable content is "Icon". Luckily the translation for my language is quite similar so with a keystroke and two mouse clicks I can quickly translate those, but having to do it more than a hundred times is quite annoying since all these could be just simplified to something like: <placeholder>Icon</placeholder> Or even better just: Icon Even if it is a massive effort and having in mind that it will require retranslating thousands of strings I fully support simplifying the strings using placeholders and removing any styling from the string if possible. This should: - reduce the number of strings, - shorten the strings thus, - making it easier to translate, - making it faster to translate, - reduce the possibility of typing mistakes, - allow to increase use of translation memory. IMHO these are big upsides making it worth the change.
Sorry for crashing the party but- documentation should be translatable article by article, not sentence by sentence. It's hard to distinguish title of a topic (article) from a regular text from a menu entry. It's not impossible but is not easy enough.
- [know it's a black magic but] think we could all benefit from a system that could extract menu entries from UI in a manner of multidimensional arrays, apply some kind of ID for every (part/level) of them and than (by hand?) edit Help markup to cross-reference ID's with new pair of tags (XML can handle this) to markup such entries in Help files by levels (as such entries sometimes are separated with regular text). This way Help entries could be automatically replaced with corresponding entries form UI -- consistently!
Menu entries should be translated automatically, not two times by hand (UI and Help) regardless of translation memory. Now small change in UI results in massive change in Help. I don't don't have every UI menu entry in my head and hate to look up when translating Help (that's the reason I'm not doing it often). Feels like a waste of time. Inconsistency in translation is what really bothers me.
I know this would be massive change but why not at least try some brainstorming and see what gives...
I would like to see some comments from translators as in if this would be useful and from developers watching this list as in if this is even possible.
Thanks, Kruno
RegardsBest regards, Sveinn30. avg. 2017 10:30 AM je oseba "Sveinn í Felli" <sv1@fellsnet.is> napisala:The AND-, OR-, XOR-operators are only a handful, anyways I translated mine capitalized as they should have been. But many strings already became (unnecessarily) fuzzy: Choose <emph><switchinline select="sys"><caseinline select="MAC">%PRODUCTNAME - Preferences</caseinline><defaultinline>Tools - Options</defaultinline></switchinline> - %PRODUCTNAME - Print</emph>. has become: Choose <switchinline select="sys"><caseinline select="MAC"><emph>%PRODUCTNAME - Preferences</emph></caseinline><defaultinline><emph>Tools - Options</emph></defaultinline></switchinline><emph> - $[officename] - Print</emph>. You see that the enclosing <emph> tag became nested for each string snippet. These are symptoms of a new editor or something different in how the markup is applied - and a very unfriendly burden on translators/proofreaders. The latter is also bloating the codebase. But are these things avoidable? Best regards, Sveinn Þann mið 30.ágú 2017 07:18, skrifaði Martin Srebotnjak:Will this patch render all these string as fuzzy for l10n teams? Lp, m. 30. avg. 2017 01:11 je oseba "Adolfo Jayme Barrientos" < fito@libreoffice.org> napisala: … and the fix is now merged for 6.0:https://cgit.freedesktop.org/libreoffice/help/commit/?id= ba1b065b296a1fce482bb3ebfa2fc8b765b45456 Thanks, Sveinn and Olivier! Adolfo -- To unsubscribe e-mail to: l10n+unsubscribe@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-- To unsubscribe e-mail to: l10n+unsubscribe@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
-- To unsubscribe e-mail to: l10n+unsubscribe@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