[wp-polyglots] New default theme missing strings

[Pandem]

Well, it seems that gettexting would be inconvenient for some reasons, 
besides turning the code unreadable. But following this thread I have 
changed my mind (since I'm not a coder myself) and think that there's one 
great advantage: it would allow full customization to any user, just by 
having the po file available to anyone and advising them to use poedit or 
anyother tool to change it and create a new mo file. For an untrained user, 
it would be easier than reading through all the files and trying to guess 
which string was translatable and which one was part of the code.

----- Mensaje original ----- 
De: "Morgan Doocy" <morgan at doocy.net>
Para: <wp-polyglots at lists.automattic.com>
Enviado: martes, 22 de febrero de 2005 1:44
Asunto: Re: [wp-polyglots] New default theme missing strings


Let's see...

HARD-TRANSLATING
Pros:
- Is easier to read, since it's in one's native language and is not
jumbled with code
- Is easier to customize
Cons:
- Requires changing themes to change translations, independent of
switching WPLANG and $locale

GETTEXTING
Pros:
- Is more modular; if theme authors included localization stuff
- Will automatically switch translations when WPLANG or $locale are
switched
Cons:
- Is difficult to customize; one would need to either replace the
message with a hard-coded customization in one's native language, or
recompile one's own custom .mo for the theme

I suppose when it comes down to it, we could do both. It would be kind
of a pain to maintain and such, but each method has its strong points.
If we were only to do one, though, it looks like hard-translating would
win out for its ease of customization, since most users like to
customize their look and feel.

Morgan

On Feb 21, 2005, at 2:35 PM, Ryan Boren wrote:

> On Mon, 2005-02-21 at 16:30 -0600, Ryan Boren wrote:
>> On Mon, 2005-02-21 at 14:17 -0800, Morgan Doocy wrote:
>>> If I understand correctly, this would eliminate the need for
>>> hard-translated copies of each theme altogether, and would instead
>>> make
>>> theme translation behavior similar to that of plugins:
>>>
>>> load_theme_textdomain("Kubrick");
>>>
>>> _e("Not found.", "Kubrick");
>>>
>>> Meaning that the /themes subdirectory of each locale in the
>>> repository
>>> would be populated not by hard-translated copies of themes, but by MO
>>> and PO files instead, nyes?
>>
>> Each locale should still provide an in-line translation of the
>> non-gettext default theme.  Reading acid ramblings is bad enough.
>> Reading them in a language that's not your own is worse.
>>
>> A gettext default theme would be offered purely to accommodate those
>> wanting to present their blog in multiple languages.
>>
>> I think we can incorporate the strings for the gettext version of the
>> default theme into the default pot.  This way the strings would be
>> translated by all projects and be present should the user decide to
>> use
>> the gettext version of the theme.
>
> On second thought, maybe we should use the theme textdomain loader.
> wordpress-i18n/pot/trunk could contain a wp-theme.pot catalog, and all
> locales would translate it.  It could be stored in
> messages/theme/lc_CC.po.  Since we're having to add gettext to the
> template anyway, adding a call to load_theme_textdomain() is no big
> deal.
>
> I'm not sure.  Either way.  Thoughts?
>
> Ryan
>
>
> _______________________________________________
> wp-polyglots mailing list
> wp-polyglots at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-polyglots

_______________________________________________
wp-polyglots mailing list
wp-polyglots at lists.automattic.com
http://lists.automattic.com/mailman/listinfo/wp-polyglots