@alagirialagiri said in what's a good minimum translation completion percentage:

@doniks I want to know whether the news section , question and answer blog posts are available in weblate translation in Tamil language.There is no navigation box available as available in documentation page.i request weblate translators to provide the language transulation Navigation box for every forum .Thanking you.

As I said before, I think it would be best to create a new post to maximise the chances that the right people can react to your questions, rather than burry your questions here in this thread. I don't have access to the blog

Ok. So, we've changed it to only English and Tamil are promoted from the start page and a few more are available in the navigation menu at the bottom

@alagirialagiri I understand you're asking me to enable Tamil translation "everywhere" in Ubuntu Touch.

Let me first remind you that Ubuntu Touch consists of many individual pieces. Many apps, websites and system components. And there is no single person that can flip a switch somewhere to enable it everywhere. Certainly, I personally don't have access to all places. Let alone that even finding all the places is probably a non-trivial task in itself.

I suggest you create a new thread here in the forum about Tamil language support and then give specific examples where you are missing the translation. I have no doubt that the community will then help to find the places where this needs to be enabled and find the right people to contact to do this.

@alagirialagiri as I said: No good justification. Other than, you know, same old ... volunteer project ... things get done when someone rolls up their sleeves and does it, not necessarily when they should be done

@alagirialagiri said in what's a good minimum translation completion percentage:

what is the reason for this status of trnslation of Tamil?

just the fact that languages need to be enabled manually and nobody has done it so far. In fact, I just turned it on a few minutes ago.

To give a bit more background.

docs are written in gitlab: https://gitlab.com/ubports/docs/docs.ubports.com in English and translated in weblate: https://hosted.weblate.org/projects/ubports/doc-ubports-com . Currently weblate has 29 languages (next to English) enabled. As far as I understand every weblate user can add a language.

The docs are set up to translate into 9 languages. A user can select the language in the bottom right corner anywhere on the docs website
.

We also prominently show the languages on the docs start page

On the one hand, thinking abstractly about this, maybe one could come up with two numbers. A low number, maybe even 0, or maybe 5, or 10 or whatever and every language that's at least as translated as that will be enabled and shown in the (hard to find) bottom right corner. Mostly as a means to promote the idea of translations and assist translators in their work. The second number would be more for, what's actually a useful level for a non english speaker to attempt to make use of their native language version. Purely gut feeling, I'd like to say ... 90% ... 80?!

But now on the other hand, in reality, out of those 29 translations in weblate, the percentages are overall quite low. In decreasing order:

• 100% Tamil
• 50% Russian
• 39% Italian
• 36% French
• 33% Galician
• 28% German
• 27% Chinese traditional

the rest are below 20%. So, considering this, I wonder whether it's justified to prominently advertise non-english versions at all - except for Tamil

Currently docs.ubports.com promotes 9 languages next to the default English version.

This selection is overdue for a reconsideration. Today it contains Romanian which is 0% translated, and it does not contain Tamil which is 100% translated.

While looking at this, I'm wondering, from which percentage on would you think it is reasonable to promote a translation. I think there should be a threshold, where if the translation is less complete than that, it's not really a service to our users to pretend that we have that language in the docs.

Indeed! Issue resolved. Docs up and running again

@Fuseteam said in Documentation temporarily offline:

hmmm according to the error this is the issue: The host is configured as a CNAME across accounts on Cloudflare, which is not allowed by Cloudflare's security policy. are the two separate accounts?

yes. both Cloudflare, but that was also true with the old setup. not clear what's different now

it also says: If this is an R2 custom domain, it may still be initializing. If you have attempted to manually point a CNAME DNS record to your R2 bucket, you must do it using a custom domain. Could it be just dns intialization? do we have other logs in the dashboard?

I don't have access to any other logs. not sure what R2 is or whether that applies to us. Not sure what this initialization is about, but the problem hasn't resolved itself since yesterday, so, I'm guessing ... whatever initialization might have been going on should have completed but that doesn't seem to have made a difference ...

also http://docsubportscom.readthedocs.io/ still works, so perhaps that could be a stopgap until we figure this out

yeah. if it works it works and can of course be used. At some point yesterday it didn't work either, but yeah, the links are there

Let me add some background (maybe someone has previous experience with this)

The source code for the docs used to be at https://github.com/ubports/docs.ubports.com/ and hosted by Read The Docs at http://docsubportscom.readthedocs.io with the custom domain docs.ubports.com configured in this RTD project. The cloudflare DNS points docs.ubports.com to readthedocs.io and that setup worked alright in the past.

In order to move over to the new repo at https://gitlab.com/ubports/docs/docs.ubports.com we've created a new RTD project at http://docsubportscom-gitlab.readthedocs.io and moved the custom domain over to this new project. But now we're faced with a "CNAME Cross-User Banned" Error 1014 instead of our docs

Contacted RTD support to see if they can help.

While updating our documentation website https://docs.ubports.com we've run into trouble with the configuration. Unfortunately that means that the docs site is not reachable at the moment. We're working on a solution.

Apologies and hopefully we can fix this soon.

For now the best stop gap is probably the last wayback version https://web.archive.org/web/20250114230013/https://docs.ubports.com/en/latest/

One thing that always confused me is why there are so many different websites to what I thought would be one thing. ubports.com, ubuntu-touch.io, devices.ubuntu-touch.io

after a cursory glance at the new designs, it seems that ubuntu-touch.io and devices.ubuntu-touch.io look more like they are one coherent thing, so that confusion might be solved.

but ubports.com versus ubuntu-touch.io I still find confusing. To be fair, I never sat down and thought about why there should be two pages and just chalked it off to ... uhm ... history ... volunteer project ... different people scratching their own itches ...

only just now, that I see this new proposal to come up with a coherent design, I thought about this again and I realize, maybe there is a good reason to have both. Because we want to tell this (complicated) story of here's the community and there's the product, and while they are linked, they are not the same, and maybe someone outside of this community/product circles could care about the distinction, because ... well, I guess because we want to cater to other projects/communities, a'la "hey <randomlinuxdistribution> look there at this great software product, maybe you want to ship it. Oh and by the way here is the community creating and supporting it" ... something like that.

so, after all this rambling let me get to one maybe actionable suggestion:

Please make it clear that one is the community and the other is the product.

e.g.

• don't start the devices page with "The ubports community is ...", but with something about devices, like "Here you find an overview of all the mobile devices capable of running ..."
• don't start the ut.io page with "We are building ... " , but "UT is ..."
• keep the clear language of "We are the UBports community" of ubports.com
• make sure (and maybe that's already taken care of in this new design) that there is a consistent top level navigation, where I guess "community" always links to ubports.com and "ubuntu touch" always links to ubuntu-touch.io , etc

Nice work @NewBit

@Moem

Phone? I think you meant to say watch... right?

err, eh, yes. sorry. fixed

I'm aware that the PineTime does not run Linux

ah. ok. then I guess I'm not really understanding the xenial/focal question. seems all I'm contributing here is confusion :see-no-evil_monkey: I shut up

@RayCulp said in Questions about contributing to the documentation:

I would like to contribute to the documentation

Thats great @RayCulp very much appreciated

• There are a number of open issues in the Github repo for the documentation. If there are no objections, I would suggest beginning with these: evaluating them to see if they are still relevant, closing the ones that are not immediately, and making updates / creating new content for the ones that still are.

Let me first take a step back and clarify that there isn't exactly an abundance of contributors to the docs.

As for how to start:

Like with many volunteer efforts, one good way to start is do what you like to do, are comfortable doing, "scratch your own itch". It's a way to create and sustain motivation for your self. If you feel like ticking the boxes of the open issues great - go for it, but it could be that some of the issues are very specific, not sure they are all up to date, or really representative of the highest priority tasks.

Another way, how I might do it, is just pick a topic or area that interests you. Read and review it and think about whether you like it as is, or want to change.

Who would be the right person to coordinate with, i.e. who is in charge of the documentation?

"in charge" is a big word, but I am the one who most consistently looks at the pull requests made

• The move from UT 16.04 to 20.04 may have rendered some sections of the existing documentation outdated. Will UT 16.04 continue to exist alongside UT 20.04? If so, might it be a good idea to preserve the existing documentation as it is, create a copy, and update the copy / create new content to reflect the current functionality of UT 20.04?

I would lean towards not doing this. It would of course be the best solution to have an extensive coverage, high quality and up to date docs for both, but I think it is just an unrealistic goal. As I mentioned there aren't a lot of contributions. So, it would be wiser to aim for a decent coverage, ok quality, and not terribly out of date for latest version only

@Moem said in PineTime $25 FOSS smart watch:

I'm wondering, does anyone here use this watch? I'd love to know whether it will worh with either Xenial's or Focal's BT stack.

used ... I have one on the shelf collecting dust and waiting for me to have time to play with it again, but note that the phone watch doesn't run UB, or any Ubuntu, or any Linux. It runs one of a selection of operating systems of your choice: https://wiki.pine64.org/wiki/PineTime#Default_OS and then it cooperates with "companion applications".

At the time when I last touched it long long time ago, I couldn't quite get to using it regularly, so it ended up on the shelf, but I am definitely looking forward to trying it again

@Shohag blast from the past what exactly does "doesn't work" mean? what's the output you get?

@arubislander said in Libertine tweak tool, how to install on Focal?:

@doniks The main issue with Libertine has always been how well the apps behave running under XMir (xenial) or XWayland (focal). No more work is being done on XMir, bit XWayland is under active development, and we should see things improving on that front.

Ah. Awesome. Happy to hear that! :party_popper:

@applee I wanted to leave it at that, but the topic keeps spinning around in my head.

I understand future proof, capacity, priorities, etc, etc, as well as scratching ones own itch, opinions being allowed to differ and above all else meritocracy. But I'll put these disclaimers aside for one more sec and look at this more strategically/architecturally.

Let's say someone writes (or updates) a solitaire game. Built with gtk/gnome, all newest best of breed, responsive design, wayland, sandbox ready, younameit. Also super standalone, wouldn't really need any platform integration to speak of as it has no notifications, doesn't read or write user files. But even if it needs any platform integration it is fully flatpak portal ready. You know, as state of the art and future proof as it gets. If we take Libertine out of the gui equation then the only way this application could come over to UT is if someone did the work to use UT's packaging format "click" to bring it in. In the previous/original vision of Libertine I would assume it to be sufficient to apt install the package from upstream ubuntu and then letting wayland be wayland.

So despite of what I said before of Libertine being basically a place to install "legacy" applications, it might be more appropriate to say upstream (apt) applications. Some of which might be "legacy" (non-responsive, X, dated stuff), but others might perfectly well be "modern" (response, wayland, etc).

But, of course, climbing down from my strategic vision horse back into reality, a lot of parts are moving: mir/wayland, upstart/systemd and if Libertine got (more) broken along the way and no one is fixing/rewriting it, then that's how it is.

@applee said in Libertine tweak tool, how to install on Focal?:

@doniks said in Libertine tweak tool, how to install on Focal?:

The future proof solution is stuff like wayland and (new) apps that are built with touch and small screens in mind. But, alas, here we are playing Libertine and trying yet again to carry the non-touchfriendly oldschool apps over to UT.

Emphasis on this part
Yeah basically convergence is the future.
In my opinion Ubuntu Touch is the best OS for it and if enough effort is made towards convergence we won't need what are distractions to me: Libertine, Waydroid, Anbox, ... Android, iOS :beaming_face_with_smiling_eyes:

Native and convergence is the way.

Well, I agree it is the future. But it has been the future for quite a while and it still hasn't turned into the present. While I'm waiting for the future I still see the need for a (multiple-years .. decades?) stopgap ...