Forum Replies Created
-
AuteurArticles
-
26 February 2009 at 22:56 in reply to: Interface de réglages des plugins ? Automatique ? [mis à jour] #383
Pour le rhume ou la grippe, « les antibiotiques c’est pas automatique ! » Tel le slogan de la sécurité sociale. Pour la doc chez Automattic et WordPress ce n’est pas non plus automatique – notamment pour ceux des développeurs qui découvrent une nouvelle version comme la 2.7.1 et le tout nouvel interface d’administration et qui n’ont pas suivi les étapes beta. Rien d’à jour dans le codex. Pas facile de trouver sur le net, avec différents mots clés, mais heureusement Heiko par un excellent article (ici) commence à ouvrir des pistes sur la façon de contruire la page d’administration d’un plugin en tirant partie des qualités de la WP 2.7.x
Dans la feuille de route, bien que l’ancien interface de la 2.3 puis la 2.5 fonctionne, les plugins xili vont intégrer progressivement les nouvelles spécifications. Nous faisons le choix de publier quelques repères en clair afin de donner envie de lire le code du plugin xili-language.
La version 0.9.5 est la dernière avec l’interface de réglages tel que défini pour les versions 2.5 et 2.6 et au delà.
La version 0.9.6 introduit tous les éléments pour intégrer les nouvelles qualités de l’interface d’administration. Pour bien comprendre les différences, le code php n’a pas été passé en mode oop avec une classe et son instantiation. Par contre, ont été intégrés les éléments et boites pour proposer :
[caption id="attachment_385" align="alignright" width="300" caption="Nouvel interface de réglages"][/caption]
– des boites (meta_boxes) toujours affichables (à gauche)
– des boites optionnelles (à droite)
– les boites peuvent être réduites à leur seul titre
– la possibilité d’arranger son écran en déplacant les boites.
Le point le plus délicat à comprendre est qu’il faut procéder par étape (lignes > n°700):
0) bien organiser les balises div avec leur id et class aux noms utilisés soit par la css du tableau de bord soit les js.
< ?php screen_icon('options-general'); ?>< ?php _e('Language','xili-language') ?>
1) déclarer les boites avec option (add_meta_box) avec la fonction qui va se charger de son remplissage mais aussi avec l’ancrage donné en résultat de la déclaration du menu nouveau du plugin et de sa fonction principale ($thehook ici)
/** * add admin menu and associated pages of admin UI * * @since 0.9.0 * @updated 0.9.6 - only for WP 2.7.X - do registering of new meta boxes and JS * */ function xili_add_pages() { global $thehook; $thehook = add_options_page(__('Language','xili-language'), __('Language','xili-language'), 'manage_options', 'language_page', 'languages_settings'); add_action('load-'.$thehook, 'on_load_page'); } function on_load_page() { global $thehook; wp_enqueue_script('common'); wp_enqueue_script('wp-lists'); wp_enqueue_script('postbox'); add_meta_box('xili-language-sidebox-1', __('Message','xili-language'), 'on_sidebox_1_content', $thehook , 'side', 'core'); add_meta_box('xili-language-sidebox-2', __('Info','xili-language'), 'on_sidebox_2_content', $thehook , 'side', 'core'); }
2) les boites toujours présentes sont déclarées dans la fonction qui affiche le formulaire (form).
/* register the main boxes always available */ add_meta_box('xili-language-normal-1', __('List of languages','xili-language'), 'on_normal_1_content', $thehook , 'normal', 'core'); add_meta_box('xili-language-normal-2', __('Language','xili-language'), 'on_normal_2_content', $thehook , 'normal', 'core');
3) dans le formulaire dans les <div> prévus, les boites sont affichées (do_meta_boxes) soit sur le côté (side) soit en partie principale (normal).
< ?php do_meta_boxes($thehook, 'side', $data); ?>< ?php do_meta_boxes($thehook, 'normal', $data); ?>4) les variables qui vont être passées dans les boîtes le sont sous forme de tableau (array).
/* form datas in array for do_meta_boxes() */ $data = array('message'=>$message,'messagepost'=>$messagepost,'action'=>$action, 'formtitle'=>$formtitle, 'language'=>$language,'submit_text'=>$submit_text,'cancel_text'=>$cancel_text);
5) enfin ajouter le petit javascript à la fin du formulaire qui a besoin aussi de la valeur $thehook (cf 1).
Et là c’est magique, les boites font ce qu’on leur impose. Le signet ‘options de l’écran’ en haut est présent. Pour quelques dizaines de lignes ajoutées, ça valait le coup.
Plus ardu est le passage en mode OOP avec class mais cela a permis d’ouvrir d’autres possibilités dans xili-language 0.9.7.1
xili-dictionary va bénéficier de ces acquis qui vont faciliter l’ergonomie de l’interface pour renseigner le dictionnaire multilingue. (c’est fait dans la 0.9.4)
MS 090226 – 090305
Le plugin ou l’extension xili-language permet d’avoir un site (un blog) WordPress multilingue. Ainsi peuvent cohabiter des articles en français et dans une autre langue comme ici sur https://dev.xiligroup.com.
L’installation se fait comme celle de tout plugin mais nécessite de vérifier que le thème utilisé a bien un codage multilingue (avec les fonctions _e() e __() comme dans le thème ‘kubrick’. Pas de texte codé en dur entre les tags comme <h2>mon titre</h2> mais <h2><?php _e(‘my title’,’kubrick’) ?></h2>.
Dans l’interface d’administration accessible via les réglages, il suffit de mettre en place la liste des langues souhaitées (ces langues doivent avoir leur fichier .mo dans le dossier du thème (par exemple fr_FR.mo, en_US.mo, de_DE.mo etc… En version alpha, xili-dictionary peut aussi créer ces fichiers .mo via l’interface d’administration sous réserve que le thème soit correctement écrit. Le programme PoEdit est aussi utilisable.Au moment de publier un article, il suffit de cocher la langue de l’article. Il sera alors classé dans la langue choisie.
Que va-t-il se passer si un internaute arrive via un moteur de recherche sur cet article ? Il va non seulement le lire dans sa langue mais aussi le thème s’afficher avec les mots de cette langue et il pourra ainsi naviguer via les termes proposés dans les menus.
Que fait xili-language ? Il utilise les mêmes fichiers .mo d’un thème multilingue normalement fixé dans la même langue que celle de l’auteur – administrateur du site (via WP_LANG dans wp-config.php) mais ici il permet un changement à la volée selon des règles de l’extension.
C’est pourquoi dans le fichier functions.php du thème, il faut commenter la ligne
//load_theme_textdomain(‘nomdutheme’);
et la faire suivre par
define(‘THEME_TEXTDOMAIN’,’nomdutheme’);
De plus quand le thème est dans une langue, l’extension modifie les liens associés (par ajout de &lang=xx_xx) aux catégories ainsi si on cherche dans celles de l’actualité, il fait une recherche dans la seule langue courante pour cette catégorie.
Cela est possible par ce que WordPress a introduit depuis la version 2.3 les tables taxonomy et terms… xili-language ajoute donc une taxinomie language avec sa clé lang (category a cat). Il est donc aisé en quelques lignes de code d’avoir des requêtes de type les articles de telle catégorie en telle langue. mais on peut aussi faire de même pour les mots clés ou une recherche. Si vous regardez bien l’url, vous pourrez voir ?cat=news&lang=en_us et si vous voulez restreindre une recherche ?s=wordpress,
il suffit d’ajouter la langue donc ?s=wordpress&lang=en_us.
et dans le cas d’un site avec plus variante d’une même langue, on aura
&lang=fr_BE,fr_FR,fr_CA !
Aujourd’hui dans la version actuelle de la taxonomie ‘language’, un article n’a qu’une SEULE langue donc de la recherche on aura les articles d’un groupe de langues.
Que faire des termes qui ne sont pas dans le thème, comme le nom des catégories et leur description ? Soit compléter le fichier .po de chaque langue et en faire un .mo via poEdit, soit utiliser xili-dictionary dans sa version actuelle de test.
La version 0.9.4 apporte la possibilité d’adapter les règles de base de modification du thème et des liens grâce à des fonctions installables dans le fichier functions.php par le créateur du thème. Par exemple, ne pas faire le changement de langue pour une catégorie donnée… ou modifier le style de la liste des langues par insertion d’une image à chacune.
22 February 2009 at 20:26 in reply to: Extend WordPress ? plugin’s addiction or theme’s functions, that is the question ! #369Want new features in WordPress: what to choose? an extension or a function in the theme functions.php ?
To begin to find solutions to this question, to collect some properties, I propose a series of questions
[caption id="attachment_372" align="alignleft" width="300" caption="WP plugin Directory"][/caption]
– Does the functionality sought only to the site, the organization of his data (data-design) and presentation (the theme, design, ergonomics)?
– Are the tools will be reusable on other sites and do their settings require the use of the interface of the dashboard by the webmaster and editor of the site (CMS) or blog?
– Are the desired features usually for the whole site or will they be allocated to the publication of each post?
– The features they cover one or more files of the theme index.php, page.php, category.php … ?
– What is the level of settings of tools ?a webmaster or as skilled publisher knowing WordPress or with a good knowledge of html and php?
Will functions use objects and modules in the core of WordPress? Also, ‘hook’, action and filter as well as’ shortcode ‘will be necessary?
Four years of using WordPress, the search for information – documentation, extensions available, tracking updates (referred to debug or upgrading), we have begun to define a first approach :
Some goals:
– Php code as short as possible.
– As much as possible: an exceptional use of javascript but can be challenged with frameworks such as jQuery or mootools.
– Keep in touch the developer of the plugin (by email or forum). Nothing worse than a tool without after-sales service especially when the update of WordPress occur.
– Limit the insertions in the header (script, css) of html page: only affected pages in order to limit potential interactions.
A few rules:
[caption id="attachment_361" align="alignleft" width="215" caption="Functions file in theme\'s folder"][/caption]
The functions that relate only to the site (CMS or Blog) are installed in fonctions.php theme developed for this site. Example: a ‘shortcode’ to make a specific layout for the authors of the site – combining, for example, text indent and insertion of an icon.
Another example: a function that determines whether an post should be displayed or not according to its category and the user’s rights (logged or not). This site has public and private areas.
The implementation of plugin to select themes (xilitheme-select) was imposed because its main function – to select the theme based on the browser (on a desktop computer or iPod / iPhone) – is independent of the themes that are in the selection. The plugin also gives other information which is used in functions and elements of the theme.
A combined approach: xili-language
This plugin changes the language of the theme’s terms according the language of the post or the displayed category. Plugin also offers « hooks » that allow the designer-webmaster of the site to add specific functions (with specific rules) to the theme (via the file functions.php).
It is possible to customize the theme in the display of the list of available languages or set of restrictive rules to changing language of the context depending on the type of posts. It is a good way to complete the approach CMS separating datas from their presentation (look).The debate is open, use the comments or the contact page.
M
22 February 2009 at 19:20 in reply to: Extension (plugin) ou fonctions dans le thème : Telle est la question. #359Souhaitez des nouvelles fonctions dans WordPress : que choisir ? une extension ou une fonction dans le thème ?
Pour collecter une série d’éléments qui vont concourir à prendre une décision, il est souhaitable de se poser une série de questions :
[caption id="attachment_364" align="alignleft" width="300" caption="Les extensions dans le tableau de bord"][/caption]– Est-ce que les fonctionnalités recherchées ne concernent que le site, l’organisation propre de ses données (data-design) et leur présentation (le thème, le design, l’ergonomie) ?
– Est-ce que les outils seront réutilisables sur d’autres sites et est-ce que leur paramétrage nécessitera l’utilisation de l’interface du tableau de bord par le webmaster ou l’éditeur du site (CMS) ou du blog ?
– Les fonctionnalités souhaitées sont-elles générales au site ou seront-elles affectées à la publication de chaque article ?
– Les fonctionnalités concernent-elles un ou plusieurs des fichiers (générateurs) du thème : index.php, page.php, category.php… ?
– Le niveau d’intervention des outils nécessite-t-il un webmaster ou un éditeur avisé connaissant WordPress ou demande-t-on à ces derniers une bonne connaissance de l’html et du php ?
Les fonctions feront-elles appel à des objets et modules du coeur de WordPress ? De même, ‘hook’, action et filtre ainsi que ‘shortcode’ seront-ils nécessaires ?
De quatre ans d’utilisation de WordPress, de la recherche d’informations – documentations, d’extensions disponibles, de suivi des mises à jour (à visée correctrice ou évolutive), nous avons commencé à définir une première approche.
Quelques objectifs :
– le code php le plus court possible.
– autant que faire se peut : une utilisation exceptionnelle du javascript toutefois pouvant être remis en cause avec des frameworks comme jquery ou mootools.– maintenir un contact avec le développeur de l’extension (plugin) car rien de pire qu’un outil sans service après-vente notamment après les mises à jour du coeur de WP.
– limiter les insertions dans les headers (script, css) aux seules fichiers, pages concernées afin de limiter les interactions potentielles.
Quelques règles :
[caption id="attachment_361" align="alignleft" width="215" caption="Functions file in theme\'s folder"][/caption]
Les fonctions qui ne concernent QUE le site (CMS ou Blog) sont installées dans fonctions.php du thème mis au point pour ce site. Exemple : un ‘shortcode’ qui va faire une mise en page spécifique pour les auteurs du site – combinant par exemple retrait et insertion d’une icône –
Autre exemple : une fonction qui définit si un article doit être ou non affiché selon sa catégorie et les droits de la personne connectée ou non. Le site a ainsi des zones publiques et privées.La mise en extension (plugin) du sélecteur de thèmes (xilitheme-select) s’est imposée car sa principale fonction – sélectionner le thème en fonction du navigateur (sur un ordinateur classique ou un iPod / iPhone) – est indépendante des thèmes qui sont dans la sélection. L’extension donne aussi d’autres informations qui sont exploitables dans les fonctions et élements du thème.
Une approche combinée : xili-language
Cette extension qui modifie le langage du thème en fonction de celui du post ou de la catégorie affichée propose des « hooks » qui permettent au webmaster-concepteur du site d’ajouter des fonctions spécifiques au thème courant (via le fichier functions.php).
Il est ainsi possible de personnaliser dans le thème l’affichage de la liste des langues disponibles ou de définir des règles restrictives au changement de langue du contexte selon le type d’articles (post) en jeu. Cela complète avantageusement l’approche CMS en séparant bien les données de leur présentation.Le débat est ouvert, utilisez les commentaires ou la page contact.
First snapshots :
To add a term (as msgid) :
[caption id="attachment_339" align="alignnone" width="300" caption="Admin UI : to add a term (msgid)"][/caption]Here below to add the french translation : (select language and « parent » or msgid)
[caption id="attachment_340" align="alignnone" width="300" caption="Admin UI : to add a term (msgstr)"][/caption]
To modify a term (msgid or after a msgstr) with tags…
[caption id="attachment_341" align="alignnone" width="300" caption="Edit a term (msgid)"][/caption][caption id="attachment_342" align="alignnone" width="300" caption="Edit a translated term (as msgstr)"][/caption]
To create on the fly the .mo file of the selected language :
[caption id="attachment_343" align="alignnone" width="300" caption="the mo file will be exported in current theme folder"][/caption]
Soon more details about the po /mo policy when languages are very close (ie fr_FR and fr_BE…)
MS 090216
Ce site est multilingue et si un article est en anglais, le contexte du thème est en anglais. On peut aussi pointer sur les articles similaires dans une autre langue. Les extensions (plugin) ont été revues pour la version WP 2.7 et intégrent des fonctionnalités très pratiques comme par exemple l’utilisation à la volée et la création des fichiers .mo du thème.
Le lien de téléchargement sur le site des plugins de WordPress. [mise à jour 0.9.3]
Why xili-language plug-in ?
When creating a multilingual theme, it is possible to add in functions.php – this line :
load_theme_textdomain('mythemename');
and in template file, each text like this : ‘this text’ is replaced in php by _e(‘this text’,’mythemename’) or __(‘this text’,’mythemename’)
example of this site sidebar:< ?php _e('Navigation','xilidev') ?>
-
< ?php wp_list_categories('sort_column=name&show_count=1&hierarchical=1&title_li=&style=list'); ?>
< ?php _e('Languages','xilidev') ?>
-
< ?php if (function_exists('xili_language_list')) {
xili_language_list();
} ?>
< ?php _e('Recent posts','xilidev') ?>
and if the theme folder contain a .mo file (i.e fr_BE) corresponding to the default language set (i.e. define (‘WPLANG’, ‘fr_BE’);) in wp-config.php, the theme’s terms are now translated.
In « default-i18n » multilingual theme ‘mythemename’ is replaced by ‘kubrick’ in – load_theme_textdomain(‘kubrick’) ; – placed at beginning of the functions.php file inside the theme folder.
Extract of first lines of functions.php :if ( function_exists('register_sidebar') ) register_sidebar(array( 'before_widget' => '
- ', 'after_widget' => '
', 'before_title' => '', 'after_title' => '
', )); load_theme_textdomain('kubrick'); function kubrick_head() {But it is impossible to change the terms on the fly ! Only the language of the theme is the language of the blog set in config.php. If you want to have some posts (some parts in the blog) in different languages, the context of the theme does not change (menu, list, category’s names or descriptions )…
Note : a multilingual blog (or cms site) does’nt contain always posts having the equivalent in another language. xili-language allow to the author to choose the language of the current post and to link to another equivalent posts in other languages. This way is more flexible. The translations or adaptations are human-made.
Coding
As short as possible : by reusing WP functions, this plug-in is very light and so easy to maintain or update.
The plugin use current WP tables, options and taxonomy tools.
If the plug-in is not activated, the theme must work : it is why the plug-in use the .mo files present in the theme folder. A theme creator must not forget to write term inside function _e(‘My exemple of title’,’mythemename’) and directly inside html tags.The webmaster can change the rules of context translations.
By default, inside the plugin file, there are some functions to ‘hook’ the way how some current tags of a theme depending the language of a post or of a category displayed in the theme. If the webmaster or the theme authors add some functions in his functions.php, it is possible to adapt the rules to the design and the CMS.
Why xili-dictionary plug-in ?
The WP source use .mo files to read translation terms dictionnary. But you need to use tools like PoEdit to build working files and upload it to the server if the translated files are not ready made by the theme’s author.
Here, with this plug-in via the admin UI, it is possible to import a .po file, to update it and to create on the fly the .mo file of the target language in the current theme folder. It is a simple tool, but it can be helpful when PoEdit is not available on your current computer.
This plug-in is not mandatory if you prefer to use PoEdit or equivalent tools. The dictionnary is installed in the terms table with a taxonomy « dictionary ». It is full compatible with xililanguage and the preset languages of your site.The blog and theme’s authors and creators corner :
What things to prepare before to activate the xili-language plugin ?
Check if all the terms of your theme are translatable (with _e() or __() functions). If a term is not translatable (ie blogname or trademark, don’t use these functions.
Create a .pot file containing all the themes terms and add in it all the terms of the categories (name and description).
Generate the .po files for each language and create .mo (ie. en_US.mo, de_DE.mo, fr_BE.mo,…)
Your theme is now international even if the plug-in is not activated.Before activating the plugin, the only thing to do is to comment the line with load_theme_textdomain() and replace it by a define to set a constant used by the xili-language plugin like here at the top of your functions.php file of the international theme (below example):
/*load_theme_textdomain('xilidev');*/ define('THEME_TEXTDOMAIN','xilidev');
Xili-language offers two new tags for theme.
xiliml_the_category()
and
xiliml_the_other_posts()xiliml_the_category() inserted in the loop (before or after each post) shows a list of the categories where the post is filled.
Here exemple used at end of each post :the_tags('Tags: ', ', ', '
'); the_author() ?> | < ?php the_date(); echo " | "; the_time() ?> < ?php if (!is_page()) xiliml_the_category(', '); ?> | < ?php edit_post_link(__('Edit This'));xiliml_the_other_posts() inserted just after the title shows the list of languages in which this post is translated or adapted. The links go to these posts.
< ?php the_title(); ?>
< ?php the_time(__('F jS, Y','xilidev')) ?> - < ?php xiliml_the_other_posts($post->ID) ?>This site and xiliphone site is powered with this plugin.
Here the download link xili-language plugin in wordpress plugin repository...
MS 090123 - updated 090305
xili-dictionary is a plugin (compatible with xili-language) to build a multilingual dictionary saved in the taxonomy tables of WordPress. With this dictionary, collecting terms from categories (title, description), from current theme (international terms with _e() or __() functions), it is possible to create and update .mo file in the current theme folder.
Some themes are multilingual (through fonctions like _e() or __()) and xx_YY.mo files inside the theme’s folder.
With xili-language, it is possible to ‘dynamically’ change theme’s language « on the fly » depending of the language of the current post or the current categories….
With xili-dictionary, it is possible in the WP dashboard, to manage the terms and the translation. All are stored in the terms tables (taxonomy and terms) of WordPress (>2.3). Some very good tools are available (PoEdit or CodeStyling Localization) but none store datas in WP Database.
xili-dictionary is able to :
– import existing .po files
– export .mo files in the target language
– import terms from the categories (name or description).
– …
So it is easy to modify translations on the fly ‘on line’…Can be used with (or not) xili-language.
Developer’s corner :
Creating and upgrading this type of plugin based on taxonomy tools of WP is a « deep » exercice. WordPress’s Taxonomy is not a easy architecture but very powerful. Now all docs are in taxonomy.php. (folder wp-includes).
As usual, dev.xiligroup try to develop plugin with few lines as possible. (with action, filter and official hooks…).
Some notes :
A term is unique (with his name and his slug) but it can be in one or more « taxonomy ». When xili-dictionary « import » a term of a category, he only create a link between the term and the taxonomy. Delete don’t delete the term attached to ‘category’ taxonomy.
To manage the languages (ie fr_FR, en_US or de_DE…), xili-dictionary use ‘slug’ as root ID. The name of the term is used for internal identification. To store msgid (one) and msgstr (each for target language), the plugin use ‘description’ field that is able to keep html tags….
So the term ‘bad words” has slug “bad-words”. His translation “mots incorrects” has the slug “bad-words_fr_fr”.
Or the term ‘the <strong>good</strong> words” will have the slug “the-good-words”. His translation “les mots <strong>exacts</strong>” will have the slug “the-good-words_fr_fr”. Column “slug” is present in the list of dictionary in UI to show terms needing translation.
A better UI, Soon more texts and instructions… (don’t forget to read the readme !)
Today – ready for WP 2.8
It is now in WordPress plugin repository .
M 090428
15 February 2009 at 23:28 in reply to: Pourquoi xili-dictionary ? Quel dictionnaire ? [mis à jour 0.9.7.2] #317Pourquoi l’extension (plugin) xili-dictionary ? Depuis la première maquette fonctionnelle, quelles sont les changements ?
Pour faire un site multilingue, il faut bien-sûr des articles en différentes langues mais il est aussi nécessaire que le cadre (thème) général du site s’adapte à la langue du (des) article(s).
Dans la première version, au lieu d’utiliser les fichiers .mo, l’extension disposait de sa propre base multilingue basée sur les tables taxonomy et terms de WordPress dont on a essayé de comprendre l’architecture apparue avec la version 2.3 de WP.
Un inconvénient majeur, dans les fichiers du thème, il fallait remplacer les fonctions ‘internationales’ _e() et __(). Ce qui n’est pas très pratique et pose problème quand le plugin est absent.
L’extension xili-language a donc été modifiée pour lire à la volée le bon .mo selon la langue du post, tout en conservant l’utilisation d’un thème « internationa ». Elle est maintenant publié ici.
Que faire de xili-dictionary ?
Un outil pour collecter les données à traduire qu’elles viennent du thème (par analyse et/ou lecture des .po existants) ou de la base (les catégories).
Un outil pour créer les fichiers .mo (et .po) du thème courant.
Bien sûr, il existe des outils comme PoEdit ou l’outil très pointu codestyling-localization qui s’intègre dans le tableau de bord de WP mais dans le deux cas, rien ne reste dans la base WP. Et de plus, en toute facilité, il est possible de changer rapidement une traduction « online » sans faire appel à Poedit installé sur votre propre ordinateur.
Pour les développeurs, cette extension est aussi un exercice exigeant pour bien comprendre à la fois la taxinomie et l’interface d’administration. De même, comme à l’accoutumée, l’idée est de faire des extensions les plus légères possibles en réutilisant au maximum les fonctions, classes et « hook » existants du noyau WP.
La version « beta » est disponible sur le site des plugins WordPress.
. L’interface est petit à petit optimisée avec maintenant des sous-sélections en cas de grandes listes mais fonctionnel – La 0.9.5 inclut un codage en OOP et l’interface incluant les potentialités WP 2.7 (meta_box, js, options UI…). La 0.9.6 est corrigée W3C et redevient compatible avec la future version 2.8 de wordpress.
Un chapître réservé aux développeurs :
Les clés de la taxinomie sont dans le fichier documenté taxonomy.php (du dossier wp-includes). Depuis sa création (WP2.3), il a progressé et on peut considérer qu’il est à maturité avec la WP 2.7.
Quelques observations clés :
De base, WP contient plusieurs « classeurs » de termes : les catégories, les tags, les liens.
Un terme qui est unique (soit par son nom (name) soit par son « slug ») peut appartenir à plusieurs « classeurs » ou taxinomies. C’est ce qui se passe quand une catégorie est traduite par xili-dictionary. Ajouter ou détruire un terme de xili-dictionary n’ajoute ou ne détruit pas le terme mais son lien avec le classeur ‘dictionary’ créé par le plug-in.
Custom Taxonomies est un plugin intéressant à ce titre mais l’auteur a recréé un ensemble de fonctions qui, pourtant, se trouvent dans le noyau WP. Mais, on peut avec cet outil retrouver le « dictionnaire ». Mais il n’est pas fait pour cela.
Pour gérer les différentes langues, xili-dictionary utilise le slug comme identifiant pivot. Le nom du terme sert pour le catalogue mais le msgid (ou le msgstr) des .po est stocké dans la description du terme afin de conserver les attributs et tags html.
Ainsi le terme ‘bad words » aura le slug « bad-words ». Sa traduction « mots incorrects » aura le slug « bas-words_fr_fr ».
De même le terme ‘<the <strong>good</strong> words » aura le slug « the-good-words ». Sa traduction « les mots <strong>exacts</strong> » aura le slug « the-good-words_fr_fr ».
La colonne « slug » a été laissée dans la liste du dictionnaire afin de détecter facilement les termes qui vont nécessiter une traduction.
A suivre… (avec le mode d’emploi…)
– mis à jour le 1/3/09 –
Xilitheme select provides an automatic selection of themes : one for current browsers and another for iphone/ipod touch browser.
The plugin xilitheme-select don’t content itself themes. The themes remain in Themes folder and are selected by the current browser and the rulers defined by webmaster. Webmaster is totally free to define (the look of) the theme on each side (deskop or iPhone). There is no automatic look transformation.
Latest release downloadable in WordPress repository :
** first public release – doc updated progressively – see also php code **
– this first release is easy to use by admin/webmasters with knowledge of WP themes.
Prerequisite:
By default:
In addition of your current selected theme add in the themes folder a theme folder named as the current with extension ‘_4touch’ dedicaced for iphone browser.Note about theme with template_page
Both themes (the current and the one for iphone / ipodtouch) must contain the same template (name) – the contents can differ obviously –admin dashboard UI:
The interface provide ways to change default extension or choose a specific fullname (for the « iphone » theme) – useful for webmaster or theme’s developer –Options
See the (documented) source of the plugin to discover other type of instantiation of the class `xilithemeselector`. One provide a way to have or not a admin dashboard interface to set the specs with only php coding.
see `$wp_ismobile = new xilithemeselector(true);` at end of code== Installation ==
1. Upload the folder containing`xilithemeselect.php` and (your) languages files to the `/wp-content/plugins/` directory,
2. Upload a specific theme for iPhone with a folder named as current theme + extension « _4touch » but don’t activate it as usual. (example and snapshot below)
3. Activate the plugin through the ‘Plugins’ menu in WordPress,
4. Go to the dashboard settings tab – Xilitheme select theme.Frequently Asked Questions
When I visit the site with iPhone or iPhone simulator, I don’t see the specific theme !
Verify that the folder of this theme has a right name with right extension.Why the option full name or extension ?
It is an easiness to choose a theme with a folder without the proposed extension.Do you provide a theme for these mobile device as iPhone or iTouch ?
Now below a link to a lite release of one our iPhone theme. (You can use also the famous iwphone theme (2007).)Why an option to disable admin UI ?
For webmaster, the UI is useful during the theme installation. And after not ! so better admin UI performances…The future ?
Written as a class, the xilitheme select plugin deliver object and vars useful for theme’s developer that are interested to provide good design for iPhone users of a website.The download links
The link of the WordPress repository : http://wordpress.org/extend/plugins/xilitheme-select/
[caption id="attachment_1566" align="aligncenter" width="200" caption="The demo Touch theme with titles as button to see excerpt."][/caption]
The link of a lite demo theme for iTouch (this theme now contains accordion features for categories list and is ready for multilingual website with plugin xili-language… and more… require WP 2.9.x): default_4touch.zip
Snapshots :
[caption id="attachment_138" align="alignnone" width="289" caption="Themes folder example with theme for iphone (_4touch)"][/caption]
By default, xilitheme select detect for iphone the theme with folder and extension « _4touch ».Now an easy way to see « iphone » in Safari on desktop computer : the safari develop menu (activation in Preferences/advanced)
[caption id="attachment_140" align="alignnone" width="274" caption="Develop Safari menu with user agent"][/caption]
Xilitheme select : Admin Settings UI :
[caption id="attachment_143" align="alignnone" width="500" caption="xilitheme settings"][/caption]In this example : in the first part, a diagnosis of the current theme and phone theme is done (1). and in (2), the webmaster has choosen the method of « full name folder ». It is useful during developing phase when evaluating different release of themes.
Updated July 27th
-
AuteurArticles