Currently we’ve just a few xliff files per package which will in the end lead to huge (unmaintainable) files. There’ve been some discussions already about splitting them up (for example like a WIP I started https://review.typo3.org/#/c/38668/)
While working on the node type translations this came up again and as we still have a bug preventing external packages to register labels for nodetypes anyway this might be somehow a good point to do some restructuring still.
Downsides:
if we restructure the current (already translated) labels we need to make sure we restructure the xml’s for all languages that contain the labels.
is this a change that is smart to do in a beta phase?
Pro’s:
the length of the used keys could be reduced because we can just try to find the key in a different catalogue
the labels will be far easier to maintain
if we change it now we don’t have to document a format / way of working we already know will change in short term
I am very open to changing this; though I am not sure whether this is still feasible for Neos 2.0. Currently, I’d rather say we should properly prepare it, and then do it for Neos 2.1. (Based on the assumption that it’s quite some work to do).
That’s exactly the reason why I didn’t want to push it forward on the last codesprint, but thinking about it again it makes a difference in the end regarding the naming.
Now we need to use some kind of poor mans namespacing like: give me the translation for key “nodetypes.TYPO3.Neos.Shortcut.properties.target” from source “Main” from package “TYPO3.Neos”
This could be changed in for example:
“TYPO3.Neos.Shortcut.properties.target” from source “NodeTypes” from package “TYPO3.Neos”
or even better:
“properties.target” from source “NodeTypes.ShortCut” from package “TYPO3.Neos”
I think it’s all still too fuzzy and as such a risk, but on the other hand building this in a backwards compatible way would cost some resources as it will add conditions to every label to be translated in the UI
Moving the labels around: probably some work, will cost some hours and should be handled with care. Doing it next year: days of work
Probably the total time including reviewing, processing of feedback and so on will easily kick it to a day of work, but I’d be willing to spend that time in a short timeframe let’s say till end of next week.
Positive side:
Nobody really started to use the Main.xliff for now as it doesn’t work at all
The documentation doesn’t have to be rewritten as it ain’t there yet
Full support from my side doing it before the 2.0 release. There’s still a lot of open tasks for the localized UI regardless, see the epic on https://jira.typo3.org/secure/RapidBoard.jspa?rapidView=19&sprint=14 so it’s still quite an open task as I see it. As mentioned before, the 2.0 release is far from stable and polished so trying to rush it will only end up in regret and disappointment I fear.
If we do this after the release I think we will have a lot of challenges and unavoidable breaking changes. I’d love to help since I’m sure it would bug me when implementing sites in the future otherwise, but unfortunately I have way to much on my plate for the time being But feel free to ping me for reviews + discussions.
And thanks for picking up and offering to do this Rens, that’s awesome
ok, imho enough “go’s” will start this weekend! Will leave the topic open for a few days just in case there’re complaints, but if nobody comments anymore I’ll close it beginning next week.
But feel free to ping me for reviews + discussions.