Closed Bug 556723 Opened 15 years ago Closed 15 years ago

[nl] l10n-mozilla-1.9.2/nl/ Fennec

Categories

(Mozilla Localizations :: nl / Dutch, defect)

Product:
Mozilla Localizations
Component:
nl / Dutch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mad_maks, Assigned: edwin.schippers)

References

Details

Attachments

(6 obsolete files)

De bug voor de vertaling van Fennec 1.1 hg clone http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/nl/mobile
Assignee: dutch.nl → edwin.schippers
Blocks: 482017
Attached patch Correcties (obsolete) — — Splinter Review
Opm.: - Klopt het dat alleen en-US Yahoo eruit heeft gehaald, of moeten anderen daarin nog volgen? Zie bug 532776 / http://hg.mozilla.org/mobile-browser/rev/4cad348ac302 - setup.ini bevat (net als en-US) Windows-line endings, en nog steeds ... i.p.v. …. Ik heb hier niks aan gewijzigd, maar laten we dit zo? Zie ook bug 482017 comment 11 e.v.
Comment on attachment 436923 [details] [diff] [review] Correcties toegepast op central en 1.9.2
Attachment #436923 - Attachment is obsolete: true
(In reply to comment #3) > Created an attachment (id=436923) [details] > Correcties > > Opm.: > - Klopt het dat alleen en-US Yahoo eruit heeft gehaald, of moeten anderen > daarin nog volgen? Zie bug 532776 / > http://hg.mozilla.org/mobile-browser/rev/4cad348ac302 ?? Yahoo zit niet in de nederlandse fennec > - setup.ini bevat (net als en-US) Windows-line endings, en nog steeds ... > i.p.v. …. Ik heb hier niks aan gewijzigd, maar laten we dit zo? Zie ook bug > 482017 comment 11 e.v. Ja anders werkt het niet, zie de zelfde bug comment 6 e.v.
(In reply to comment #5) > > > > Opm.: > > - Klopt het dat alleen en-US Yahoo eruit heeft gehaald, of moeten anderen > > daarin nog volgen? Zie bug 532776 / > > http://hg.mozilla.org/mobile-browser/rev/4cad348ac302 > ?? Yahoo zit niet in de nederlandse fennec Dat zei ik ook niet, maar wat ik bedoel is dat de regel (6) met ‘browser.search.order.2=Yahoo’ nog wel aanwezig is in region.properties, en dus de genoemde changeset wellicht is gemist? Dit is echter ook zo in enkele andere talen, vandaar de vraag.
Ah, goede vangst dan. Inderdaad gemist, ik denk dan ook dat de regel genegeert wordt tijdens het bouwen.
(In reply to comment #5) > > - setup.ini bevat (net als en-US) Windows-line endings, en nog steeds ... > > i.p.v. …. Ik heb hier niks aan gewijzigd, maar laten we dit zo? Zie ook bug > > 482017 comment 11 e.v. > > Ja anders werkt het niet, zie de zelfde bug comment 6 e.v. Als het bestand niet UTF-8 of win-1252 gecodeeerd is, kan daar niet een escape voor gebruikt worden? \u2026 oid? ~Laurens
aanpassing in browser.dtd en toevoeging van passwordmgr.properties. Dit is m'n eerste patch, dus als het niet klopt dan hoor ik graag wat ik verkeerd gedaan heb. Mvg, Edwin
Welkom. :) Niet schrikken, er zijn wel een paar kleinigheidjes/wetenswaardigheden: - De patch heeft bij het toevoegen aan de bug het type ‘octet-stream’ gekregen; type ‘auto’ zou voor patches goed moeten gaan (het wordt dan type ‘patch’ - eventueel kun je dit nu nog wijzigen). - De patch bevat ANSI-codering i.p.v. UTF-8 (zonder BOM). De Unix-linefeeds zijn wel goed. - Er ontbreekt een newline aan het eind van het bestand. - Er ontbreken wat aangepaste/kloppende (en liefst ook geteste) access keys. - Er is hierin soms sprake van gebiedende wijs i.p.v. infinitief / hele werkwoord, terwijl we dit laatste aanhouden (dus ‘Wijzigen’ i.p.v. ‘Wijzig’, ‘… verwijderen’ etc. - Schakelopties en dialoogvensterteksten (zoals ‘rememberValue’) krijgen in de regel geen punt. Tip: kijk goed naar de bestaande bestanden/teksten voor FF.
Dank voor de feedback, weer wat geleerd. Ik zal morgen nog eens een poging doen. Ik had een aantal teksten overgenomen uit bestaande vertalingen, maar ik zal daar nog eens kritisch naar kijken. Die codering komt denk ik door m'n editor. Kwam er net ook al achter dat de standaard teksteditor van mac soms een beetje een eigen weg in gaat. (In reply to comment #11) > Welkom. :) Niet schrikken, er zijn wel een paar > kleinigheidjes/wetenswaardigheden: > > - De patch heeft bij het toevoegen aan de bug het type ‘octet-stream’ gekregen; > type ‘auto’ zou voor patches goed moeten gaan (het wordt dan type ‘patch’ - > eventueel kun je dit nu nog wijzigen). > - De patch bevat ANSI-codering i.p.v. UTF-8 (zonder BOM). De Unix-linefeeds > zijn wel goed. > - Er ontbreekt een newline aan het eind van het bestand. > - Er ontbreken wat aangepaste/kloppende (en liefst ook geteste) access keys. > - Er is hierin soms sprake van gebiedende wijs i.p.v. infinitief / hele > werkwoord, terwijl we dit laatste aanhouden (dus ‘Wijzigen’ i.p.v. ‘Wijzig’, ‘… > verwijderen’ etc. > - Schakelopties en dialoogvensterteksten (zoals ‘rememberValue’) krijgen in de > regel geen punt. > Tip: kijk goed naar de bestaande bestanden/teksten voor FF.
Attachment #443111 - Attachment is patch: true
Attachment #443111 - Attachment mime type: application/octet-stream → text/plain
In de orginele bestand is er ook geen newline en zijn de acceskeys ook leeg dus dat klopt, verder sluit ik me aan bij de opmerkingen van Ton
http://www.frenchmozilla.fr/glossaire/nl hier kan je de engelse of nederlandse tekst invoeren (of entity) zodat je kan zien of en hoe het vertaald is in andere mozilla produkten. succes p.s. Ton "remembervalue" heeft in het orgineel ook een punt.
aanpassing in browser.dtd en bestand passwordmgr.properties toegevoegd (2e poging)
Attachment #443111 - Attachment is obsolete: true
Comment on attachment 443355 [details] [diff] [review] aangepaste patch n.a.v. foutjes in de vorige. Je bent op goede weg! maar: - Een acceskey moet in het woord voorkomen en mag nog niet eerder in hetzelfde menu gebruikt zijn. +showPasswords=Toon Wachtwoorden +showPasswordsAccessKey=P kan dus niet - Wat mij betreft laat de lege regels in het engels ook in het nederlands leeg - In het nederlands gebruiken we alleen een hoofdletter aan het begin van een regel of bij namen en niet zoals in het engels bij elk woord. Dus "Toon wachtwoorden" - http://www.frenchmozilla.fr/glossaire/nl/index.php?recherche=Show+Passwords laat zien dat we Ẅachtwoorden tonen" gebruiken in de toolkit en dan moet het ook zo vertaald worden in de andere producten (of je moet met een voorstel komen om het aan te passen in de toolkit)
Attachment #443355 - Flags: review-
Attached patch wederom aangepaste patch. (obsolete) — — Splinter Review
aanpassing in browser.dtd en passwordmgr.properties toegevoegd
Attachment #443355 - Attachment is obsolete: true
Ik sluit me aan bij de opmerkingen van Tim. We komen er wel. ;) +hidePasswordsAccessKey = V / +showPasswordsAccessKey=T -> access keys graag identiek houden aan het echte teken (maar hier beter allebei W) Vergelijk ook even http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/locales/en-US/chrome/passwordmgr/passwordmgr.properties en http://mxr.mozilla.org/mobile-browser/source/locales/en-US/chrome/overrides/passwordmgr.properties Goed beschouwd is dit bestand, op het kleine verschil in regel 51 en de niet-aanwezige access keys na, volledig identiek aan dat van Fx 3.6 (ook te zien via http://mxr.mozilla.org/l10n-mozilla1.9.2/source/nl/toolkit/chrome/passwordmgr/passwordmgr.properties). Het lijkt me dan ook logisch dat bestand te gebruiken en aan te passen, of in elk geval de teksten daarin te hanteren. Als iets echt anders/beter kan, dan kan dit zoals Tim al zei ook in de toolkit worden aangepast, wat vaak lastig is, omdat de toolkit i.h.a. alleen te wijzigen is via wijzigingen voor FF (in een eigen bug) en deze soms ‘op slot zit’. (In reply to comment #14) > p.s. Ton "remembervalue" heeft in het orgineel ook een punt. Klopt, maar dit is dan ook een foutje/inconsistentie in en-US. ;)
Comment on attachment 443579 [details] [diff] [review] wederom aangepaste patch. patch is toegepast op 1.9.2 en central met 1 aanpassing +hidePasswords = Wachtwoorden verbergen +hidePasswordsAccessKey = W +showPasswords = Wachtwoorden tonen +showPasswordsAccessKey=W zodat hij gelijk is aan het toolkitbestand
Attachment #443579 - Attachment is obsolete: true
https://l10n-stage-sj.mozilla.org/dashboard/compare?run=47651 nog een paar dingen en dan kunnen we een sign-off doen
aanpassing in aboutHome.dtd en toevoeging van crashreporter/crashreporter-override.ini
Comment on attachment 444280 [details] [diff] [review] aanpassing in aboutHome.dtd en toevoeging van crashreporter/crashreporter-override.ini toegepast
Attachment #444280 - Attachment is obsolete: true
Attached patch Kleine verbeteringen (obsolete) — — Splinter Review
Ik denk dat het zo wat beter/consistenter wordt, en ook de commentaren worden weer Engels. N.B. ‘browser.search.order.2=Yahoo’ is nog steeds aanwezig (zie comment 6).
Comment on attachment 444332 [details] [diff] [review] Kleine verbeteringen toegepast, en yahoo verwijdert
Attachment #444332 - Attachment is obsolete: true
(In reply to comment #24) -<!ENTITY aboutHome.noTabs "Geen tabbladen van de laatste keer"> +<!ENTITY aboutHome.noTabs "Geen tabbladen van de vorige keer"> moeten we "<!ENTITY aboutHome.recentTabs "Uw tabbladen van de laatste keer">" dan ook niet veranderen? (viel me op bij het testen voor de sign-off)
(In reply to comment #26) > > moeten we "<!ENTITY aboutHome.recentTabs "Uw tabbladen van de > laatste keer">" dan ook niet veranderen? Goed gezien. :) Mee eens dus. We zouden overigens kunnen overwegen om in beide regels ‘de vorige _sessie_’ te gebruiken i.p.v. ‘de vorige keer’, dat is wellicht wat netter en duidelijker. Als we dit doen, geldt dat uiteraard ook voor FF (zie startupLastSession.label, dat niet geheel toevallig ‘LastSession’ bevat). Voor en-US geldt denk ik hetzelfde, zowel voor FF als Fennec. Meningen?
Het is een vorm van sessieherstel dus ik ben voor "vorige sessie" Edwin wat is jou mening?
persoonlijk zou ik niet over sessies beginnen. Gewoon om rekening te houden met users die niet echt denken in sessies (de wat minder technische mensen). Volgens mij is het doel om het taalgebruik zo algemeen mogelijk te houden. dus houden zoals het nu is zou ik willen voorstellen. gewoon laatste keer blijven gebruiken.
Ik heb de versie niet getest, dus over een sign-off kan ik niets zeggen. Alleen de kwestie uit comment 26 geldt nog. Hoewel Edwin in comment 29 wel een punt heeft, pleit ik toch voor het gebruik van ‘sessie’, omdat dat ook op heel veel plaatsen elders voorkomt (in FF althans), en dus het begrip voor bestaande Firefox-gebruikers niet zo vreemd zou mogen zijn. Daarbij is “de vorige keer” een vorm van spreektaal, dus IMO niet echt gepast in een softwarevertaling. Aangezien de huidige FF-versie echter nog steeds op een belangrijke en vergelijkbare plek ‘keer’ gebruikt, is het weliswaar een optie om het nu ‘keer’ te laten en dit bij de volgende versies van zowel FF als Fennec ‘sessie’ te maken, maar dat is misschien vergezocht en eigenlijk kan het in Fennec net zo goed nu worden aangepast, en dito voor FF 3.7, dan wel de volgende 3.6.x. Dit geldt hier dan voor zowel aboutHome.recentTabs als voor aboutHome.noTabs. Overigens is het in beide gevallen wel ‘de vorige’; ‘last’ wordt (net als ‘latest’ overigens) wel vaker per abuis als ‘laatste’ vertaald, terwijl hiermee in veel gevallen ‘vorige’ resp. ‘meest recent(e)’ wordt bedoeld.
Goed gezien, ik dacht dat ik het al verandert had in "vorige keer" maar blijkbaar niet. Ga het nu doen.
Aangezien ik geen tegenberichten hoor ga ik nu een sign-off doen.
voor Fennec 2 gaan we door in Bug 482017
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: