Opened 10 years ago

Closed 10 years ago

#2067 closed defect (fixed)

Potlatch can't handle i18n strings which overflow the boundaries of its dialog boxes which are hardcoded for English

Reported by: avar Owned by: richard@…
Priority: major Milestone:
Component: potlatch (flash editor) Version:
Keywords: Cc:

Description

From localised.yaml:

"prompt_helpavailable": Nýr notandi? Skoðaðu hjálpina með því að smella á hjálpartakkann neðst til vinstri.

Then see the screenshot.

Attachments (1)

potlatch-fail.png (27.3 KB) - added by avar 10 years ago.
BAN POTLATCH

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by avar

Attachment: potlatch-fail.png added

BAN POTLATCH

comment:1 Changed 10 years ago by avar

This seems to be a systemic problem in Potlatch, e.g. editinglive exhibits the same problem.

To reproduce it just try making every string in some Potlatch locale twice as long as it currently is and watch it screw everything up.

comment:2 Changed 10 years ago by avar

Summary: Potlatch's info screen will overflow with i18n strings longer than it expectsPotlatch can't handle i18n strings which overflow the boundaries of its dialog boxes which are hardcoded for English

comment:3 Changed 10 years ago by Richard

This is kinda inevitable, I'm afraid, unless you either a) have a whole UI framework to sort this out, or b) make all the dialog boxes very big for the most verbose language.

ActionScript? 1 doesn't have such a framework and I don't have the time or energy to code one. Potlatch 2 will use the Flex framework for ActionScript? 3 which should probably do a better job of sorting this out.

Until then, though, there are two quick wins:

  • Are there any particular dialogue boxes which are consistently too small, and where a reasonable amount of enlargement would improve usability for many users without compromising it for others?
  • Are there any textfields which are actually too small and the text is being cropped rather than just overflowing?

comment:4 in reply to:  3 Changed 10 years ago by avar

Replying to Richard:

This is kinda inevitable, I'm afraid, unless you either a) have a whole UI framework to sort this out, or b) make all the dialog boxes very big for the most verbose language.

One workaround which might be viable would be to take the length of the string into account whenever you create text fields with createTextField, for instance here:

    function setEditingStatus(str,col) {
        _root.createEmptyMovieClip("status",62);
        _root.status.createTextField("btext",1,0,-1,90,20);
        with (_root.status.btext) {
            text=str;
            setTextFormat(boldWhite);
            selectable=false; type='dynamic';
        };

Instead of hardcoding 90 you could determine the width based on the length of str. How long you can get away with that before doing collision detection I don't know.

ActionScript? 1 doesn't have such a framework and I don't have the time or energy to code one. Potlatch 2 will use the Flex framework for ActionScript? 3 which should probably do a better job of sorting this out.

Until then, though, there are two quick wins:

  • Are there any particular dialogue boxes which are consistently too small, and where a reasonable amount of enlargement would improve usability for many users without compromising it for others?

I filed this bug on general terms since it seemed to me to be a general problem (and I stopped translating Potlatch as soon as I noticed that I couldn't do so due to this bug).

Pretty much all the i18n strings in Potlatch have a corresponding call to createTextField which will have its width hardcoded to whatever just about fits for the English string. To see this in action try to apply this patch to localise2.pl:

$ svn diff
Index: localise2.pl
===================================================================
--- localise2.pl    (revision 16600)
+++ localise2.pl    (working copy)
@@ -43,7 +43,7 @@
            while ($tr=~/\%([^%]+)\%/g) { $tr=~s/\%([^%]+)\%/\$$substitute/;
                                          $substitute++; }
            unless (exists $translations{$lang}) { $translations{$lang}=''; }
-           $translations{$lang}.="\"$id\": $tr\n";
+           $translations{$lang}.="\"$id\": FOOBAR $tr\n";
        }
        unless ($ct) { print "WARNING: no translations read\n"; }
    }

(Incidentally this will also give you a clear indication of what strings are currently untranslatable)

Just adding 7 characters to every string in the program will almost universally cause Potlatch to overflow its UI elements.

comment:5 Changed 10 years ago by Richard

For those strings that are displayed on a single line in the English version (i.e. most of them), I hope I've fixed it in 1.2a - to be committed this evening.

(This will sometimes mean the text overflows the bounds of the dialogue box. Shit happens.)

For those which are displayed on more than one line, it's not practical to programmatically resize the textField in case of overflow. That would require a whole UI framework malarkey. So I'll need to enlarge the textField to the largest practical extent - assuming that the translators aren't too prolix :) - and would appreciate feedback on this.

comment:6 Changed 10 years ago by Richard

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.