[sp1ritCS]

Match libappstream and only operate on the local name, irrespective of actually set namespace.

Kinda nasty, but sadly necessary when having to deal with namespaced and namespaceless files :/.

[ximion]

There is no namespace for AppStream Metadata that we defined - so shouldn't we rather make that namespaced stuff fail validation and reject it outright? Either that, or we do officially define a namespace, but until we do that, I think we should just reject namespaced data, since it is not compliant with the specification (which, while not explicitly forbidding namespaces, does not name one and has no example of using one).

[sp1ritCS]

I know that using a namespace is 'discouraged', but the way I understand the manual, adding xmlns="https://specifications.freedesktop.org/metainfo/1.0" is allowed.

[ximion]

Right, I forgot we added that... It is not at all a great idea in pretty much all cases, and I am not even sure it validates correctly, since absolutely nobody tests this.

Why do you need a namespace? Why can't you just drop it?

[sp1ritCS]

I am not even sure it validates correctly

It does, since libappstream really only ever gets the name of the node trough xmlNodes name member, which is just the local name, so it ignores whatever (if any) namespace is set on the nodes.

Why do you need a namespace?

The application manifests gtk-android-builder operates on, are expected to embed an appstream manifest within /pw:app/pw:metainfo, typically by XIncluding the already existing appstream manifest of the application. As the pixiewood manifests have a namespace, embedding the appstream manifest within them without them setting their own namespace results them being tagged as part of the pixiewood namespace (or not if the manifest uses xmlns:pw="..." instead of xmlns="...").

I did originally implement it that way instead of the other way around (pixiewood information within appstream custom tags), due to the custom tags not being flexible enough for storing the multi-layer application icons and by now the pixiewood manifests contain stuff that really shouldn't be part of the appstream manifest (configure options, etc.)

[sp1ritCS]

The metainfo.its shipped as part of GNU gettext has essentially all its rules duplicated, one set with the https://specifications.freedesktop.org/metainfo/1.0 namespace and one without: https://github.com/git-for-windows/git-sdk-64/blob/main/mingw64/share/gettext-1.0/its/metainfo.its (can't link to upstream due to both their cvsweb and cgit being down)

While this technically doesn't match what libappstream is doing, that approach would work for me too, should you prefer it.

[sp1ritCS]

bumping this - @ximion do you have a preference for one or the other approach? The lack of support is causing non-insignificant issues for us when using xgettext, which I'd like to see resolved.

[ximion]

The application manifests gtk-android-builder operates on, are expected to embed an appstream manifest within /pw:app/pw:metainfo, typically by XIncluding the already existing appstream manifest of the application. As the pixiewood manifests have a namespace, embedding the appstream manifest within them without them setting their own namespace results them being tagged as part of the pixiewood namespace (or not if the manifest uses xmlns:pw="..." instead of xmlns="...").

A bit of an odd usecase, but, this does make sense. Do you have an example project to look at?

I do think we should probably have this solution, as it works independently of whether there is a namespace or not. Although namespaces are extremely uncommon in MetaInfo files.

[sp1ritCS]

Do you have an example project to look at?

In GTK, the manifest for the gtk4-demo looks like this: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/build-aux/android/org.gtk.Demo4.xml#L4 and XIncludes https://gitlab.gnome.org/GNOME/gtk/-/blob/main/demos/gtk-demo/org.gtk.Demo4.appdata.xml.in after it has been processed by meson (that still uses the old appdata name, but the same works for metainfo ones ofc.).

Although namespaces are extremely uncommon in MetaInfo files.

They might become a little more common now, given that we're effectively suggesting that app developers that want to port their app to android add that to their metainfo :)

[ximion]

I finally got time to play with this. With your change applied, it worked for namespaced MetaInfo files, but non-namespaced ones did not get translated properly anymore (which of course, isn't okay).

I came up with the solution in ab782c6 based on your PR - please have a look to see if this works for you! It duplicates the paths, but I think that that's probably unavoidable for broad support, and given the limited set of translatable elements, it's not that bad (we very rarely also add any new ones).

Thank you for the patch and for finding this issue!

[sp1ritCS]

Wierd that this approach doesn't work for non-namespaced files for you, since I'm pretty certain it did for me, but your approach works for me too (after all, that what GNU gettext does too). Thanks for looking into it.

[ximion]

Wierd that this approach doesn't work for non-namespaced files for you, since I'm pretty certain it did for me

Maybe I did something wrong, that's definitely possible!