>Thanks JM. Still got some questions though. If we need them we need
>them, but just seems to be a lot in there that can be inferred from
>other sources.
>
>> # $Id: en-GB.ini 11557 2009-02-01 03:33:14Z robs $ // this is made by
>> SVN when the language files are created/updated this way. Majority of
>> Translators do not use SVN, thus the need for some supplementary metas
>> as described below.
>
>Yeah, that one is fine.
Sure, but please do not forget that most TT or 3pd don't use svn.
>
>> # Core // this defines if an ini file is Core or 3pd. Reason is
>> package making. Until now all inis in the core language folders were
>> included in the a pack when using the Translation Manager. There was
>> no way to separate these.
>
>So what happens? Does the package maker parse each file to look for
>that attribute?
Yes. And it works easily and flawlessly. It also
permits differentiating files in com_localise UI.
>
>Why aren't you working off the list of core extensions in the database?
Much more complex IMO and does not take into
account the main en-GB.ini or the specific
xx-XX.whatever.menu.ini, if I do not mistake.
+ the fact that as extensions are added, nothing
differentiate them from Core ones in the db as
far as I could see in jos_extensions.
>
>> # Client Site // this is to avoid confusion between Site and
>> Administrator ini files when they have the same name. Also of use when
>> creating packages. For Core and also for 3pds.
>
>We have the problem with components as well. The solution is to put
>the "client" files in sub-folders of the package file (been available
>since Joomla 1.0). I really don't think this is necessary to nominate
>as com_localise can work it all out.
We do know these files are in sub-folders to be
installed in their proper place, whether in core
folders or in their respective language folders
and the packaging will take this into account
when creatins specific language install packs,
only possible in core folders.
The meta makes it much easier to deal with.
Think of 2 files with same name,
one is in administrator/components/mycomponent/language/xx-XX/
the other in components/mycomponent/language/xx-XX/
or both in the respective Core language folders
Com_localise will pick these files and make a
combined install pack for a new language for this
component.
Another issue are the plugins who may need their
inis (when proposed by the 3pd dev in the plugin
language folder) installed in both admin and site
core language folders when creating a new
language, for them to function properly.
Yes, we could do without it for com_localise, but
would not that be easier for a casual Translator,
specially for someone editing manually?
>
>> # Version 1.6 pre-alpha // In fact, this is not the Joomla version
>> only. This becomes necessary when the Translation Team coordination
>> has to control the update of packs provided by the Translation Teams
>> when Joomla version is updated, as we can't control when a specific
>> ini has been updated or not. Can be # Version 1.6v1, v2 or # Version
>> 1.6.1, 1.6.1v1, etc.* 1.6 or 1.6.1 are related to the Joomla version,
>> v1 or v2 etc. to the language pack version.
>
>I can live with the Joomla version, but why couldn't the Id tag (the
>revision number) serve the same role as the "v" numbers. Or, I am not
>understanding why the "v" numbers are significant.
# id meta is only created/used by SVN working
people and most translators don't use it.
This means that the SVN version as well as the
date are 99% of the time incorrect in the id.
In fact they would only be correct if each
language was recreated from scratch based on the
original reference file
It is also true for 3pd ini files.
The "v" version is used when users/translators
discover that a Translation pack is missing a
string or a string has been wrongly translated
-after releasing their pack. In this case the TT
makes a new pack and states the v in the pack
name. This adds to figure out which version of
the language pack one deals with as it is shown
nowhere after the language has been installed.
This will show in com_localise UI.
>
>> # Desc Joomla! English(GB) // Used to know which language is concerned
>> and for which specific usage i.e. Jooma core or 3pd. For 3pd, the name
>> of extension should be added instead of Joomla! i.e. # Desc
>> Mycomponent English(GB). This provides for easier identification of
>> the file when SVN is not used i.e. when edited manually or through
>> com_localise.
>
>I have a problem with this being different for core and 3pds - that's
>confusing. But why for core do you need the language name when it can
>be looked up in the XML file. The file name also tells you what the
>language is. For 3pd's, the file name also tells you the language and
>where it applies to (which extension). Just don't like the idea of
>doubling up information that we already have, that's all.
Understand your concern. Redundancy is to avoid when not necessary.
This meta is to cope with Translation Policy
http://community.joomla.org/translations/typical-language-file-headers.html
to replace
# Joomla! [full language name in clear] Translation
We need to have this field present in
com_localise to add the Language Name and
"Translation" term when necessary
It would also be used for 3pds inis and I think
it is not confusing, it takes of confusion by
adding information.
The older Translation Manager was very confusing
in its UI, could not differentiate core and
non-core files, did not have to deal with the new
implementation of local language folders, did not
make any other install packs than core ones.
If we implement these metas, we not only make for
com_localise a user and feature friendly UI but
also help basic users know precisely what is what
when they open an ini file. And this makes it
easier for all. How many times did I have to ask
on the forums which ini file and where it was in
Joomla when a user was asking help?
JM
--
Merci de ne pas renvoyer de pièces attachées automatiquement.
------------------
Jean-Marie Simonet/infograf
info...@orange.fr
http://www.info-graf.fr