kempelen
@Robin The files are unnecessarily full of & # 13; entities, which are probably remaining trash from an aged DOS-to-Unix file format conversion or similar step.
I think they cause the weird double enter on Transifex GUI. (Attached a picture with such double enter.)
In HTML terms they play no role, especially at line end, they are a Carriage Return character from the usual \ r \ n new line sequence, so being on line end, which ALREADY behaves as a space on rendered HTML they just do nothing. They just cause difficulties for translators and also caused some hours of extra work for me now in trying to process the files. Claude recommends to remove them. But of course I understand you cannot update the English files currently, so this is not something you can do currently, but maybe a note for later. Here is final analysis from Claude Code, but it was so much stuck on errors caused by “something” (either these or not) that I needed to keep pushing it: this cannot be the cause. Finally agreed. (Partial conversation from a whole day sequence…)
Q: And do you find it reasonable that a HTML parser would not descend into the table for cells in a structure like <div
id=”main-menu”><table id=”menu-table”><tr><td>… (with no text content in between div and table) (unless there is
other structural errors)?
● No, I don’t — and your skepticism is well-founded. I need to correct my earlier explanation, because I got the
causation wrong.
Looking back at the actual test sequence:
– po4a-updatepo -f xhtml without -o untranslated=pre → 54 entries (this was run on stripped files)
– po4a-updatepo -f xhtml -o untranslated=pre → 4 entries
The stripped files without the option gave 54 correct entries. That means
removal was harmless all along. The
single cause of the low extraction count was always and only -o untranslated=pre — the conflict with po4a’s internal
_default_translated registration for PRE tags. The
stripping was coincidental noise that happened at the same time,
and I incorrectly blamed it.
So: you can safely strip
from the source files if you want cleaner PO strings, and the note in pullall.sh about
keeping them is wrong. The cleaner approach would actually be to re-enable the stripping in pullall.sh and get rid of
msgids like “
5500 which is used to listen…”.
Want me to re-enable the stripping in pullall.sh, re-download the files, and regenerate the POT? It would clean up a
fair number of noise strings in hu.po.
✻ Cogitated for 1m 10s
—
Now, that is a very hard decision for me here, right before starting to translate. Because if I remove the Carriage Return entities LATER, then many-many-many strings will become “fuzzy”.
So I think I’ll do the following in this pilot project for FAQ-HU: I do remove them, do the translation, and see if HTML pages look OK and see if Transifex accepts the files back. If Transifex does not accept them, but HTML works perfect, I will probably need to submit outside Transifex, and later on if they are removed from base files, … that would cause “fuzzy” for everyone who already translated so maybe we will NEVER remove them…..
- This reply was modified 4 months, 1 week ago by kempelen.
- This reply was modified 4 months, 1 week ago by kempelen.
