Fixes and changes to Lokalize, request for feedback

[Emir SARI]

Hello,

> Karl Ove Hufthammer <karl at huftis.org> şunları yazdı (2 Ağu 2024 21:30):
> 
> Yes, HTML text is annoying. But I find that the colouring of the HTML tags very useful to distinguish markup from (often translatable) text.

Colouring is nice, but something like easy keyboard navigation between strings to translate would be invaluable in terms of saving time.

> You can also run ‘posieve check-tp-kde’ to test your files for markup errors. BTW, there used to be automatic check-tp-kde error reports sent to this mailing list. I don’t know why they stopped.

Will use this, thanks.

>> 2. HTML preview. As most of you might relate, each time I see a huge block of HTML tags, I need to open a HTML previewer website to make sure I don’t mess up anything.
> 
> Yes, a HTML (and KUIT) preview feature would be nice.
> 
> 
>> 3. Actually readable HTMl tag colour. That purple is unreadable, and outright irritating while translating documentation where there are a lot of predefined tags.
> 
> I actually find it very readable. But perhaps you’re using a dark theme? Anyway, it should be easy to fix (the colour it’s probably hardcoded instead of using colours from the user’s colour scheme). Can you file at bug at Bugzilla?

It’s the dark theme. At least something like a proper .po highlighting theme support like in Kate would be nice, and user friendly. I’ll file a bug.

>> 4. Fixed width font by default.
> 
> Hm, why? Most of the text we’re translating will *not* shown with a fixed-width font, so I’m not sure why a fixed-width font would be an advantage.
> 
> 
>> 5. 80 column indicator line.
> 
> Again, why? The strings will typically be reformatted both by Lokalize when saving and by msgmerge when merging. (Though personally, I have set Lokalize to *not* reformat the strings when saving.)

A couple of reasons:

- We also translate text to be displayed on a console. Being able to keep a certain column width will make sure that the text will look nice on the minimum 80-column terminal windows, and no unwanted text wrapping will ensue.
- Fixed width fonts will ensure that manual text formatting or alignment will be kept, especially for tabs and stuff.
- Some text views also do not wrap by default. It’s nicer to be able to keep a 80-column width, especially for modal dialogues.

>> 6. Option to disable automatic completion. Never use it. Slows me a lot.
> 
> This has been implemented since February 2010, just a few months after the autocompletion feature was first implemented (https://bugs.kde.org/show_bug.cgi?id=227399). I don’t use the feature (found it annoying) and have always had it disabled.

How do we disable it?

> An option to ignore tags could be useful, but, personally, I sometimes find it useful to search for (if not *in* HTML tags).

I was recently changing all the single and double quotes and the other ASCII characters with their Unicode equivalents, and it is really hard to automate it with the HTML tags in equation.

>> Below suggestions will help a lot with professional looking texts, a la Apple-level professional text. The new HIG also includes these:
>> 10. Automatic smart single and double quotes
>> 11. Automatic en, em dash formatting. Two for en, three for em.
>> 12. Unicode character suggestions. If there is a ASCII ligature, offer to replace it with Unicode characters, for instance for arrows, ellipsis’, dashes etc.
>> 13. Smart character suggestion. For instance offer to change 1 x 1 into multiplication sign, offer to change hyphen into minus sign when used with mathematical operations etc. Greater sign, less than sign etc. etc.
> 
> Also this should preferably be implemented as an autocorrect feature in KTextEditor (used by Kate, Kwrite, Lokalize etc.). But if implemented, it would be safer to keep it by disabled by default. Having " and ' turned into “” and ‘’ will break HTML markup.

Yes, KTextEditor should be the place for this. This feature would ideally omit the HTML tags, and just use the translatable strings for changing this. Also in some places, these quotes should stay as is, especially in programming-related applications.

Thanks for all the comments.

Best regards,
Emir (𐰽𐰺𐰍)

** E-mail needs to stay simple
** Use plain text e-mail