search

bgarrels / textpattern

Automatically exported from code.google.com/p/textpattern
0 stars 0 forks source link

Core plugin l10n and i18n method #45

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
A common method to store and edit texts for plugins at monolingual sites
would be helpful. My primary concern are user-visible strings, but plugin
help texts might also be a target for this issue.

A solution should help both plugin authors and site owners. Authors could
distribute a set of translations with their work, while site owners could
add local strings for the plugin to use, and eventually redistribute a
language set back to the community or plugin author.

Original issue reported on code.google.com by r.wetzlmayr on 24 Sep 2009 at 9:10

GoogleCodeExporter commented 9 years ago

Original comment by r.wetzlmayr on 24 Sep 2009 at 9:11

GoogleCodeExporter commented 9 years ago 
Am I reading this right...steps to make it core functionality to publish 
multilingual
sites?

Original comment by destry.w...@gmail.com on 24 Sep 2009 at 12:12

GoogleCodeExporter commented 9 years ago 
No. We research a standard method of handling l10n texts for plugins, similar 
to what
the core does at Admin > Prefs > Languages. Currently, translating a plugin 
either
means a user has to patch a plugin's code, or each single plugin author devises 
a
custom method to render l10n-aware text. Cumbersome.

This does not imply any form of remote infrastructure (language server).

Original comment by r.wetzlmayr on 24 Sep 2009 at 12:20

GoogleCodeExporter commented 9 years ago 

Currently, Textpattern updates any txp_lang row whenever a language update from
rpc.textpattern.com occurs. An additional boolean column 'system' in txp_lang 
could
serve as a flag to discriminate between "system"-owned string which are to be
replaced from the lang server upon every update, and "site"-owned strings which 
must
not be written by the core. "Site"-owned string could be administered by 
whatever
hits your fancy, from phphMyAdmin and plugin-intrinsic methods up to a 
specialised
"Language Manager Plugin". 

Non-core strings would have to be clash-protected using our common
three-letter-prefix convention, like so:

INSERT INTO txp_lang (`lang`, `name`, `event`, `data`,  `system`) VALUES 
('en-gb',
'wet_sample', 'common', 'Lorem ipsum', 0) ;

Original comment by r.wetzlmayr on 3 Dec 2009 at 2:09

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision r3322.

Original comment by r.wetzlmayr on 3 Mar 2010 at 11:00

GoogleCodeExporter commented 9 years ago

Original comment by r.wetzlmayr on 9 Mar 2010 at 11:32