Just to add to the discussion, although I can see that Amy's patch already
provided for this case, I think it should be standardized the combined use of
the ISO 639-1 or 639-2 language codes and the ISO 3166-1 alpha-2 country codes,
forming language codes like en-GB, pt-BR, eng-US, spa-ES, etc.
This is to force 3pds to use the same schema, since I've seen 3pd extensions
using only the ISO 639-1 / 639-2 codes, because it's the only one alluded to in
any Joomla doc on languages I could find so far.
Hi all,
First of all, thx Amy for the note on Twitter ;-)
The white paper I wrote is only a replacement for the very unlucky
implementation of a language tag in the params of com_content
currently. For any 3rd party application that deals with multi lingual
content this would be already perfect.
Related your idea with the source field.
I'm not sure if this is a beneficial at this state. This field will
create a kind of revision reference to the original content which has
a lot of dependencies or additional requirements. Personally I would
leave the handling of these revisions to the 3rd party extensions as
you can either solve it the way Joom!Fish is doing it or you can also
use something like the currently developed versioning system for such
a solution. It depends on the needs. In all cases having a source_id
field will not be relevant for the extension as they need to maintain
the references themselves. I know its a change to my original white
paper.
My notes about the questions:
> - Should source queries be changed to restrict results based on Language?
I would say no.
The reason is that adding a where element for only the articles will
create a complex understanding why it is being implemented for
articles but not for other tables/information. The other topic is that
the queries can become really complex and in these cases the condition
will not be simple anymore. Side effects are possible.
>Translation Extensions would then focus on copying source documents into a new
>row and presenting work to the appropriate translator for other
>languages. No
>additional logic should be required to present the language needed for
>the site
>visitor.
I would not second this. There are many more issues you need to focus
on and just doing a copy of an row is also not causing the fact that
less additional logic is used. For one table such as content this
might be right, but still the result for the user and admin might be
quite complicate. The primary issue at this point is the reference to
other entry in our database (e.g. menus, categories, ...).
Ithink it's better to set the source_id to be the same as id (for the
Before developing, I would like to know too.
Hi all,I personally feel that this thread drifted into a direction that was not intended by me with writing my white paper in the first place. Now the response from Gergö was from end of August and now I hear that com_content might get some over-whole already in 1.6.
Ok, I remember now. Let me continue to get the lay of the land on
things and see where it heads. I’m really mid-stream at the moment
and I don’t really know where it’s going to end up so can’t give you
an opinion one way or the other. Sorry.
> So, is the release team still involved?
Yes, but are busy with their studies just at the moment.
> Or, are we using different
> approaches now?
You’d have to ask the Production Leadership Team and/or the Release Team.
> We all stopped on this topic when the release team set it
> aside. Might be a good time to get a handle on what's all remaining. Alex
> added the plugins refactoring to the Docs today. Maybe we should update the
> 1.6 status page? See where everything is at?
There are a number of things in the works to provide more status
information for the general public. I suggest those with development
time on their hands introduce themselves on this list (if you haven't
already) and ask where they can be most help or read the several posts
already active with task lists. As you can appreciate things can
change from day to day at the detail level that development status
pages can't really convey. If in doubt, ask.
> I know Gergo stepped away for awhile. Might be time to bring in a closer -
> get Wilco to get his bossy Project Mgr self back in here and organize
> things. He drove a hard whip getting 1.5 in, that's for sure! hehe!.
Personally, and this is just me, I’m quite happy with the way things
are closing. More bodies would be better and probably change what
those higher up in the leadership chain do (eg, I can mentor more).
Can’t really give you a definitive answer on that one because it’s
relative to who’s available at any point in time. Regarding Wilco,
his expertise and experience in unquestioned and when he’s ready to
get involved again I’m sure he’ll act on it in his own time.
> The two fields were 1) the language code and 2) the original content key.Ok, I remember now. Let me continue to get the lay of the land on
> The link to the patch is in this thread. Yea, what you are talking about is
> certainly more complex. I have not heard of that yet.
things and see where it heads. I’m really mid-stream at the moment
and I don’t really know where it’s going to end up so can’t give you
an opinion one way or the other. Sorry.
Yes, but are busy with their studies just at the moment.
> So, is the release team still involved?
You’d have to ask the Production Leadership Team and/or the Release Team.
> Or, are we using different
> approaches now?