![]() I would see this as the logical path as well. > component where people contribute, submit patches and gain commit rights. Localization and Perl: gettext breaks, Maketext fixes a.k.a.> I could imagine that an Bugzilla skin could become a Phoenix.Detect localizable strings missing in lexicon (would fallback as auto entries anyway).po.tmpl files to accomodate $terms changes ( bug 469734) Clone and translate English lexicon to other languages.Translate English lexicon: expand tokens to full error messages, replace bug(s) with %quant(,bug) calls, and bug with $terms.bug.Convert all Perl code loc() calls ( bug 469734).Convert all templates to l() filter calls ( bug 412161).Script to hunt for localizable texts in templates (inspired by mkanat's attachment to bug 407752).: collect localizable strings from templates and code.Bugzilla::L10N setup and lexicon loader.maketext() support for command line scripts.Specify and implement (English) %quant() and %numerate() calls.Generic Locale::Maketext capability ( bug 469732).Now they'll need to work with message catalogs. do not wrap paragraphs at all.īefore Locale::Maketext only single knowledge was required from custom template maintainers: Template Toolkit. Not a problem with special PO editing tools, but their template files look accordingly, i.e. Request Tracker indeed uses long keys, up to 400 characters on a single line. "From here you can manage everything regarding your participation\n" Other projects using Maketext and Template Toolkit also confront this:Īct! ended up with keys cut at first newline: Long texts as %Lexicon keys are not so handy, with their multiple explicit newlines, leading spaces, etc. Perhaps we should add function helpers to more filters. L(" bug(s) were found in products.", bugs, products) %] Products = BLOCK nproducts FILTER html END Real situation is even worse because most variable pieces are unsafe and require FILTER html. Msgstr "%quant(,$terms.bug was,$terms.bugs were) found in %quant(,product)." Msgid " bug(s) were found in product(s)." Msgid "0 bug(s) were found in 0 product(s)." bug(s) were found in products.", nbugs, nproducts) %]Īnother option to consider is Locale::Maketext::Fuzzy: Example: before (without numeric inflection logic) Real-life examples can be seen in bug 412161 attachments.įrequent calls may obfuscate templates. One can merge both, based on line numbers of English templates, and copy other ( LANG) side of a diff into msgtxt. Message catalog with its msgid/msgtxt pairs is very similar to unified diff between template/en and template/ LANG trees. However, nearly all required texts already exist somewhere in templates. With current logic, it would serve Russian instead of Japanese.Īfter English lexicon shakedown localizers may start the bulk of translation work. en.po - English messages for template/en/customĪnd then we get a request for ja, ru, fr language preference.template/ru/custom - old translated set.template/en/custom - custom set, refit with maketext. ![]() Template search path logic is not changed either: translated template/ LANG/default would take precedence over maketext-converted template/en/default and LANG.po file.īest language is not so easy to glark anymore: suppose we have All existing templates, custom or default, English or localized, would still work. Maketext support by itself does nothing to change templates. This way global/ would be used only during, to compile. Msgstr "$terms.Bugzilla – Enter $terms.Bug" To ease such customizations (and to provide backwards compatibility) en.po would be preprocessed from en.po.tmpl: So default English templates may safely refer to 'bugs', and leave the rest to l10n logic. In object-oriented spirit of Maketext, application should not care about how to say something, just what to say. po files we need for a single instance? Is single file enough or do we split web, command line and email domains? po/ LANG.po or locale/ LANG.po Why not create a separate dir?Īnother question is: how many. po files to merge the lexicon unneeded exposure to http server. ![]() Drawbacks: need to iterate through multiple. template/ LANG//*.po Advantages: site and project level customizations possible. pm files there is no good place besides Bugzilla/L10N/ LANG.pm Bugzilla/L10N/ LANG.po Most obvious, used by many projects. po files, more convenient to localizers community because of mature tools pm modules with explicit %Lexicon entries ![]() See also #Default template look and feel below Large boilerplate text, no lines changed, filter added as separate lines. In fact, l and loc, | and FILTER are synonyms.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |