Closed Bug 569670 Opened 15 years ago Closed 15 years ago

Missing and untranslatable strings on Student Reps

Categories

(Websites :: studentreps.mozilla.org, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Tobbi, Assigned: craigcook)

References

()

Details

Attachments

(2 files)

The following strings are currently not translatable: http://studentreps.stage.mozilla.com/de/help: "Need help?" "A little more info to get you started." (translatable in the PHP file but not appearing in Verbatim) http://studentreps.stage.mozilla.com/de/marketing: "Keep apprised of Mozilla news" (not in the language file) http://studentreps.stage.mozilla.com/de/highlights: "Student reps make us proud" (Missing dot at the end in the language file. That's why it's not picked up correctly). Apart from those issues, German should have 100% coverage.
Oh, and I forgot one thing: Success Stories is hardcoded in http://viewvc.svn.mozilla.org/vc/projects/studentreps/trunk/inc/content/home-content.php
Craig, can you look into comment #0?
I believe I've fixed these in r68356, for German and all the other languages. Fingers crossed I didn't miss one.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
There are another bunch of missing strings: http://studentreps.stage.mozilla.com/de/projects many strings under the subheadings 'Verbreite die Botschaft', 'Starte eine Bewegung', 'Lerne von Mentoren und Erfolgsgeschichten Anderer', 'Wähle, wie du Unterstützung anbieten willst' are not translated. Same goes for 'Keep apprised of Mozilla News' and everything under 'So kannst du mithelfen' on http://studentreps.stage.mozilla.com/de/marketing
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Craig, can you take another look at this? Thanks!
Assignee: nobody → craigcook.bugz
These were a batch of late-round content updates that were made after l10n was already underway (mostly just punctuation). So the updated copy on the page wasn't matching the copy in the .po files. I think I've caught them all as of r68788 but localizers should be on the lookout for any more strays.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
I've translated some new strings (current revision is r68792), but several strings are still missing on the staging page, on <http://studentreps.stage.mozilla.com/de/projects> and in the contact form on <http://studentreps.stage.mozilla.com/de/help>. Setting bug to Reopened.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The staging site still doesn't look right. There are still strings missing, as explained in comment #7.
I'm also seeing missing strings on the Albanian localization, even though Verbatim notes it as 100% completed. http://studentreps.stage.mozilla.com/sq/projects http://studentreps.stage.mozilla.com/sq/marketing http://studentreps.stage.mozilla.com/sq/highlights Craig, is this also related to the content updates mentioned in comment 6?
At this point I have no idea why those few sentences aren't showing up in the proper language. The strings match in the content and in the language file, and I'm not familiar enough with gettext to hazard any other guesses. SethB, can you spare a few minutes to look into this?
IMO, the .po files in verbatim need to be updated from svn with the newest strings, I opened the .po file from SVN and it is 63% complete, not 100%.
compiling the gettext files manually on my local copy gives me a fatal error: Compiling all locales... Compiling fr/LC_MESSAGES/messages.po ... fr/LC_MESSAGES/messages.po:541:45: Séquence de contrôle invalide msgfmt: 1 erreur fatale trouvée done All done. this is due to this entry: #: ../inc/contact-form.php:82 #, php-format msgid "The e-mail address you entered doesn\'t look like a complete e-mail address. It should look like <em>yourname@example.com</em>." msgstr "" I believe «doesn\'t» shouldn't be escaped neither in the pot file nor in localized files. Regenerating a .pot file removes that escaping, my guess is that this entry was added to the pot file manually and not via extract-po.sh My recommendation would be to remove this escaping characters in all .po and .pot files and then rerun the extract-po.sh script. This way the po files will be updated with the latest strings and the cron job running on the server will be able to compile new .mo files (and importing the .po files to verbatim would probably be without bugs, I suspect that because od that, the imports or partial). That's what I found while skimming the code but I may have not covered all issues since I am not the most versed in gettext esoterics in the l10n team ;)
(In reply to comment #12) > compiling the gettext files manually on my local copy gives me a fatal error: > Compiling all locales... > Compiling fr/LC_MESSAGES/messages.po ... fr/LC_MESSAGES/messages.po:541:45: > Séquence de contrôle invalide > msgfmt: 1 erreur fatale trouvée > done > All done. > > this is due to this entry: > #: ../inc/contact-form.php:82 > #, php-format > msgid "The e-mail address you entered doesn\'t look like a complete e-mail > address. It should look like <em>yourname@example.com</em>." > msgstr "" > > I believe «doesn\'t» shouldn't be escaped neither in the pot file nor in > localized files. Regenerating a .pot file removes that escaping, my guess is > that this entry was added to the pot file manually and not via extract-po.sh I've been making minor edits by hand because I don't actually have gettext installed locally, so I may have introduced some of these problems inadvertently. But in this instance that apostrophe needs to be escaped because it's part of a JavaScript, and an unescaped ' breaks the script. BUT, we can simply instead use &#8217; and it should solve both issues. I've changed to the encoded entity in r69146. I edited manually once again, and still can't run any of the scripts, so if you'd be so kind as to recompile and see if this fixes anything...
using an entity or harcoding escaping is not the solution because the string is going to be replaced by the translated string which may or may not have a quote in it, what you should do is use addslashes() to all the strings you use in javascript: $("#errors").html("<p><?= addslashes(_('The e-mail address you entered doesn't look like a complete e-mail address. It should look like <em>yourname@example.com</em>.')) ?><\/p>"); This should be done for all strings used as javascript variable, including those without a quote letter in English actually.
Updated with addslashes in r69194
the template pot file and po files are updated with all the currently used strings on the site in r69200, I don't have any error compiling the files locally so the cron job should work now
Attaching a text file listing the English strings I currently see on the ES and DE translations. Only two files currently show English strings: projects.php and marketing.php
That's 'Fuzzy' strings that need to be marked as non-fuzzy in the po file via poedit or verbatim
Who should mark those strings as non-fuzzy? The owner for that locale? Or Craig? Thanks
the owner of the locale should.
es has been updated in SVN, could you, please, check if all is correct?
I've "un-fuzzied" all the strings and fixed some errors, but there's still one paragraph, that's not translated on the German staging page: the last paragraph on <http://studentreps.stage.mozilla.com/de/marketing>. The current revision is r69230, could you please check, what's wrong there? The relevant strings begin in line 1293.
Michael, I know what's wrong there (some white space was removed in the source code so I have to regenerate the po files with that change, it will probably mark a couple strings as fuzzy). I am on 3.6.4 stuff this evening so maybe I'll do that afterwards, depends on when the release is done, otherwise I'll do that tomorrow.
(In reply to comment #22) > I've "un-fuzzied" all the strings and fixed some errors, but there's still one > paragraph, that's not translated on the German staging page: the last paragraph > on <http://studentreps.stage.mozilla.com/de/marketing>. > The current revision is r69230, could you please check, what's wrong there? The > relevant strings begin in line 1293. That block of text is an unordered list and I think the various line breaks and whitespace in the markup are triggering a mismatch. It might be preferable to treat each list item as a separate string to simplify translation. So I've changed the markup in r69277. This means there are a cluster of new strings to translate but hopefully it'll solve this problem. Also it looks like the heading "Firefox Education Toolkit" is translated as "Firefox Education Toolkit" in German... the original English is in the translation field so it registers as translated, but it's still English. Perhaps just an oversight?
Now it seems, there's only one missing sentence, the last one on the marketing page. I don't see any new strings in the po file, though. I think „Firefox Education Toolkit“ isn't translated, because we could'n think of a German translation for that, yet.
I've lost even Verbatim commit access now, in addition to not being able to svn commit. Until this get fixed, I'm attaching here the latest messages.po for sq.
Besnik, I had the svn repo fixed to be available to localizers, you can commit via svn now.
When I look at the pages, only one string is now appearing in English (on all locales). It appears on the bottom of marketing.php: "Follow us on Twitter and join us on Facebook. Help retweet and comment on Facebook postings to spread the word."
I have updated the po files, these strings should now be in your po file (svn up to get the latest version if you translate via poedit, click on the "update from VCS" link if you use Verbatim to get the new strings there).
I've checked in r69424 to translate these strings, but the translations aren't visible yet.
Now the strings are visible, thanks for your help.
de now shows the translated string from comment 28 on marketing.php. Still waiting for es, sq, and hu.
I believe we can finally call this resolved. There are a few bits still untranslated in hu but that's not due to this bug, and this one is a blocker for the release so I'm calling it. Any future l10n issues for student reps can be treated as new bugs.
Status: REOPENED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: