Pokrewne
- Strona Główna
- James Shore, Shane Warden agile development. filozofia programowania zwinnego pełna wersja
- (ebook computers) Visual C .NET Developers Guide
- Borland Delphi 7 Developer's Guide
- Gilstrap John Za kazda cene
- Cunningham Elaine Obrzed Krwi
- Hobb Robin Misja blazna
- LeGuin Ursula K Opowiadania orsinianskie
- Agatha Christie Uspione morderstwo (2)
- Lew Tołstoj Anna Karenina
- John Grisham Klient
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- streamer.htw.pl
[ Pobierz całość w formacie PDF ]
.It is possible to view the repository by languageand extension, or by extension and language.The breakdown uses directories, sincethe file names are simply the name of a language together with the standard.pofile extension, and hence there will be many files with the same name.The schemealso allows for the possibility of alternative translations of the same extension bydifferent translators.An entry can be created by uploading an archive containing the extension, which isexpanded, and processed by gettext.The service has to be run on hosting wherethe gettext package is installed so that the scanning of PHP code for strings to betranslated can be done.This kind of service must be installed with extreme care, as it involves theuploading of PHP code.Barriers must be in place to ensure that it is impossible to maliciously upload andexecute PHP that would damage the site.Scanning of the code results in an initial POfile without any translations, and it is stored at the top level of the repository, under the appropriate CMS extension.When a translator decides to work on a new translation for a CMS translation, first alanguage is selected.A directory is created of the form CMS extension/language/translator, and the initial PO file for the extension is copied here.The translator isthen able to use the translation utility to create translated strings, and store them inthe new PO file.The translated PO file is available for download by anyone wantingto use the translation.If a new version of the CMS extension is created, it can be uploaded again, and anew basic PO file is created.The new PO file is merged with any existing PO filesfor the same CMS extension.Any new or changed strings will need translation; theextension will function without this, except that the new or changed strings willappear in the base language.[ 217 ]LanguagesTo assist in the transition from language files that use PHP define, the utilities atthe Aliro developer site also provide for the conversion of the definition text (usingthe English language file) into the T_('xxx') format.Once converted, the languagefile can be used for the automatic gettext scanning process, so as to pick up alllanguage strings used by an extension.Translation can then be done using thestandard gettext approach described above.Substitution at run time will be a twostage process, where a symbol is defined to have a value, and the value is computedusing the T_ function, which returns an appropriately translated string.By thismeans, an existing extension can be converted at minimum effort, although in thelonger term it is better to adopt the normal style of using T_ where a text string isneeded rather than in a separate file of definitions.Installing Translations with CMS ExtensionsTo accommodate the need for PO language files with CMS extensions, the definitionof the packaging XML is extended.Full details of this are given in Appendix A.The relevant features of the XML are the langdir attribute on the install tag andthe tag.The former specifies where the language files will be placed,relative to the extension's directory.In the case of components, which have adirectory in the main directory structure and another within the administratorstructure, the language directory is relative to the main directory, since allinformation that is needed on both sides should be held in the main directories.The latter contains one or more tags, each of which has a "language"attribute that gives the name of the language for which the file contains translationsin a form such as es or fr-CA.With the information provided in the XML, the installer is able to place theextension's PO files into a language directory.At the same time, it uses code from thePHPGettext group of classes to convert any PO file that matches a language installedin the CMS into a MO file.The MO file is placed in the CMS directory structurefor the language concerned, using the unique formal name of the extension as thedomain name, and thus the name of the MO file.Any existing MO file for the samedomain is overwritten by the new installation.When a CMS extension is deleted, theextension handler class removes any MO files that belonged to it.This means that the languages provided with a CMS extension are automaticallyaltered if the extension is upgraded, since in relevant respects, upgrade has the sameeffect as removing an extension and installing a fresh version [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl agnieszka90.opx.pl
.It is possible to view the repository by languageand extension, or by extension and language.The breakdown uses directories, sincethe file names are simply the name of a language together with the standard.pofile extension, and hence there will be many files with the same name.The schemealso allows for the possibility of alternative translations of the same extension bydifferent translators.An entry can be created by uploading an archive containing the extension, which isexpanded, and processed by gettext.The service has to be run on hosting wherethe gettext package is installed so that the scanning of PHP code for strings to betranslated can be done.This kind of service must be installed with extreme care, as it involves theuploading of PHP code.Barriers must be in place to ensure that it is impossible to maliciously upload andexecute PHP that would damage the site.Scanning of the code results in an initial POfile without any translations, and it is stored at the top level of the repository, under the appropriate CMS extension.When a translator decides to work on a new translation for a CMS translation, first alanguage is selected.A directory is created of the form CMS extension/language/translator, and the initial PO file for the extension is copied here.The translator isthen able to use the translation utility to create translated strings, and store them inthe new PO file.The translated PO file is available for download by anyone wantingto use the translation.If a new version of the CMS extension is created, it can be uploaded again, and anew basic PO file is created.The new PO file is merged with any existing PO filesfor the same CMS extension.Any new or changed strings will need translation; theextension will function without this, except that the new or changed strings willappear in the base language.[ 217 ]LanguagesTo assist in the transition from language files that use PHP define, the utilities atthe Aliro developer site also provide for the conversion of the definition text (usingthe English language file) into the T_('xxx') format.Once converted, the languagefile can be used for the automatic gettext scanning process, so as to pick up alllanguage strings used by an extension.Translation can then be done using thestandard gettext approach described above.Substitution at run time will be a twostage process, where a symbol is defined to have a value, and the value is computedusing the T_ function, which returns an appropriately translated string.By thismeans, an existing extension can be converted at minimum effort, although in thelonger term it is better to adopt the normal style of using T_ where a text string isneeded rather than in a separate file of definitions.Installing Translations with CMS ExtensionsTo accommodate the need for PO language files with CMS extensions, the definitionof the packaging XML is extended.Full details of this are given in Appendix A.The relevant features of the XML are the langdir attribute on the install tag andthe tag.The former specifies where the language files will be placed,relative to the extension's directory.In the case of components, which have adirectory in the main directory structure and another within the administratorstructure, the language directory is relative to the main directory, since allinformation that is needed on both sides should be held in the main directories.The latter contains one or more tags, each of which has a "language"attribute that gives the name of the language for which the file contains translationsin a form such as es or fr-CA.With the information provided in the XML, the installer is able to place theextension's PO files into a language directory.At the same time, it uses code from thePHPGettext group of classes to convert any PO file that matches a language installedin the CMS into a MO file.The MO file is placed in the CMS directory structurefor the language concerned, using the unique formal name of the extension as thedomain name, and thus the name of the MO file.Any existing MO file for the samedomain is overwritten by the new installation.When a CMS extension is deleted, theextension handler class removes any MO files that belonged to it.This means that the languages provided with a CMS extension are automaticallyaltered if the extension is upgraded, since in relevant respects, upgrade has the sameeffect as removing an extension and installing a fresh version [ Pobierz całość w formacie PDF ]