Feature request: generate translations from node-type #47
Comments
|
It would also be cool to have the option too create a new translation file from the context menu
With a small |
|
@PRGfx @crydotsnake If you're brave enough, you might try this version: https://plugins.jetbrains.com/plugin/9362-neos-support/edit/versions/eap/550359 This adds a context menu action for nodetypes "Translate NodeType". You'll need to configure your locales first. The action should trigger a notification with a link to the settings page. Best if you backup your files before. |
|
Thank you for your work @cvette! I installed
The IDE logged an exception. (Many other plugins throw this error, so probably not relevant:) There are some edge-cases with overrides, I think. # My.NodeTypes/Configuration/NodeTypes.Base.yaml
My.NodeTypes:Text:
ui:
label: i18n # My.NodeTypes:NodeTypes.Text:ui.label# My.Website/Configuration/NodeTypes.Overrides.Base.yaml
My.NodeTypes:Text:
ui:
label: i18n # overriding a single label in the distribution is realsitic
help:
message: i18n # alternatively add a new label to the existing nodetype
# everything here is My.NodeTypes:NodeTypes.Text:ui.label etc. (regardless of package where _this_ file is)
My.Website:Text
superTypes:
My.NodeTypes:Text: true
# tweak behavior, add additional properties
# this might have a label of My.NodeTypes:NodeTypes.Text:ui.label, but My.Website:NodeTypes.Text:properties... etc.
# however if a property is "redeclared" (i.e. we have a new ui.label=i18n), the label from the My.Website package would be usedThis setup with the overrides probably isn't realistic like this, but both approaches individually make sense to me. As both nodetypes in this scenario have the same name, afaik we could have <xliff ...>
<file product-name="My.NodeTypes" ...></file>
<file product-name="My.Website" ...></file>
</xliff>From what I understand, they could reside in different xlf files, as long as the |
|
I tried |
|
Thanks for your detailed feedback!
This doesn't seem to be the issue. At least I wasn't able to reproduce it this way. I suspect the problem occurs somewhere in this method: https://github.com/cvette/intellij-neos/blob/main/src/main/java/de/vette/idea/neos/actions/TranslateNodeTypeAction.java#L373C18-L373C46 Do you have any additional plugins installed that might handle XLIFF files? Would you be able to debug this further? That would help a lot. |
|
Phew, that was quite a journey... in the end it turned out that apparently I registered However, I don't know if this happened automatically, based on a suggested action, as the file "looks like" XML or because of a plugin that might have come and gone since. So I could imagine, that others might be affected as well – maybe the take-away is only a troubleshooting info in the README. |
When creating translated node-types I often find myself writing down the definition with all the "i18n" labels and later open both the node-type and a translation file side-by-side to see which strings I need – sometimes trying to remember what that label of the node-creation-dialog label was etc.
I think it would be really handy to have a context action on node-type definitions to generate xlf files, maybe even on a "label"-basis.
For each language (i.e. folder in Resources/Private/Translations) it would create a file based on the node-type name and stub all properties etc. (e.g. everything with "label: i18n" (or
help.message,formatting.placeholderetc.) and a "mappable" path (i.e. we know how to mapui.label,properties.*.ui.labeletc. but would maybe ignore other paths).The default-language could be configurable in the plugin settings. Maybe it would make sense to have the stub configurable as well.
I recognize that it's more difficult to update a translation file (i.e. reading the XML and writing it back - in the best case while preserving comments or whitespaces).
If that would be possible however, it would be a cool context-action to of course just update the translation file and "extract a string" into a translation.
In any case I think it might be possible to get the "content" of
/xliff/file/bodyas string, write it back and appendtrans-units for new properties/translatables if no matchingtrans-unitidwas found in the file.The text was updated successfully, but these errors were encountered: