:) nice!

🎉 it works:

Ok, the .htaccess was actually not generated by Hugo but located in the static directory. I pushed to the server let's see if its work. ;)

Is there no way of getting Hugo to append given content to the .htaccess it already generates?

Hugo already generate a .htaccess in public, so this configuration need to be added in the apache conf :(

Christoph is correct here, our systems permit the use of .htaccess files, so you should be able to use the Apache Rewrite module without anything being needed on our side
(Note that RewriteBase will probably not be required)

kate-editor.org should have the module enabled and you should be able to just add some .htaccess with such rules to the hugo static files dir.

@cullmann thanks for the hint, I come up with this 404 handler written using mod_rewrite.

Hmm, beside that, can one not simply fix that by using a 404 handler that does the redirect? I did that once for the AbsInt page, just rewriting the url to the generic english page if the original url ended up in 404.

Too bad that partially translated stuff doesn't work :/
I only read a bit in the above thread on discourse: is there actually a real bug report that requests support for this?

Ok I was able to work around some of the limitations of Hugo. I added a redirection in javascript, the user experience is not very nice since we need to wait at least 5 seconds before being redirected. For example https://kate-editor.org/uk/build-it/

I added a language picker in kate-editor.org and I have bad news, hugo doesn't support partial translated website. Either the entire website is translated or it's not and a lot of dead link are created, because Hugo doesn't provide any fallback to the default language.

@nalvarez hi! Do you have any news about this task? Can we help?

Translations with Hugo and po4a works 🎉 See https://kate-editor.org/about-kate.uk/ or https://kate-editor.org/about-kate.pl/

In overall Plasma, we typically simply use longer lines. It's not been an issue.
A good editor (such as kate) will wrap in a way that shows the indent properly anyway.

In T11721#202182, @pino wrote:

! In T11721#202172, @aacid wrote:
FWIW you can do

    text: i18n("bla \
hola")

and it will work, but note the hola needs to start at column 0, probably your strict code style doesn't allow for that either.

This was suggested: https://phabricator.kde.org/D23783#527600
... and not accepted by the maintainer either because "ugly".

! In T11721#201558, @romangg wrote:
If not via newlines could it be possible to make it work by combining strings with +? Like:

i18n("Lorem ipsum dolor sit amet, consectetur adipisici elit, " +
     "sed eiusmod tempor incidunt ut labore et dolore magna aliqua.")

Not sure why this doesn't work at the moment. Is it because of this xgettext tool?

That makes me think that the problem lies more on the QML side not accepting multi-line strings like:

FWIW you can do

the i18n team manpower is close to zero.

@ltoscano I added the StaticMessages.sh script. It should now works ;)

As I mentioned, you need to create a StaticMessages.sh file in your repository, which expose the two twin functions (export_pot_dir/import_pot_dirs if you deal with multiple pot files or export_pot_file/import_pot_files if you have just one), following the example of websites/docs-krita-org, plasma-browser-integration or other projects (kdeconnect-android, for example).
The only thing I can do on the translation side is to enable the extraction for that repository, but you need to write that script.

@ltoscano I merged the change in the kate-editor.org repository. The https://kate-editor.org/about-kate/ page should now be translatable. Can the Localization team do the necessary scripty change?

In T11721#201559, @ltoscano wrote:

i18n("Lorem ipsum dolor sit amet, consectetur adipisici elit, " +
     "sed eiusmod tempor incidunt ut labore et dolore magna aliqua.")

• even if that is fixed, the two strings would be still considered separate and extracted separately; there is no way to say that they are really the same string (otherwise weird things can happen if a variable is part of a concatenation). The string should really be a unique string.

In T11721#201557, @romangg wrote:

Just to reiterate when I say that I will enforce the rule it means that I will do this while keeping other priorities in check, in particular that "functionality is more important to me". What I don't want to see is commits breaking the rules without giving me notice, prior discussion and a path forward. That's why I reverted the original commit.

In T11721#201558, @romangg wrote:

If not via newlines could it be possible to make it work by combining strings with +? Like:

i18n("Lorem ipsum dolor sit amet, consectetur adipisici elit, " +
     "sed eiusmod tempor incidunt ut labore et dolore magna aliqua.")

Not sure why this doesn't work at the moment. Is it because of this xgettext tool?

In T11721#201554, @mart wrote:

as my personal 2 cents user facing strings are so important that they should exampted by that rule (or even the frameworks coding styles amended"
for QML, it's not easily changeable, and in general having javascriptis always kindof dangerous having newlines that aren't strictly necessary, as the interpreter can always think "let's try to put a ; in there and let's see what happens"
for qml, we should really have separate coding styles, that don't diverge from kdelibs where make sense, but the kdelibs ones really are c++ specific ones

In T11721#201553, @ltoscano wrote:

[...]
I find the fact that you want to give a stricter interpretation of a rule like this, which also affects other community members, a bit over the line with the powers of a maintainer. It should be part of a community discussion inside your project at least (Plasma), if not a more general one. I also personally find the fact that this is a "will" without adding a "if possible" a bit too strong; see below.

as my personal 2 cents user facing strings are so important that they should exampted by that rule (or even the frameworks coding styles amended"
for QML, it's not easily changeable, and in general having javascriptis always kindof dangerous having newlines that aren't strictly necessary, as the interpreter can always think "let's try to put a ; in there and let's see what happens"
for qml, we should really have separate coding styles, that don't diverge from kdelibs where make sense, but the kdelibs ones really are c++ specific ones

In T11721#201552, @romangg wrote:

In T11721#201551, @ltoscano wrote:

This is not off-topic, because the limit you are trying to enforce is not an absolute limit, as stated in the same code that you are quoting. It's not about "code style can just go to shit". If the QML does not allow to have this, well, either fix QML (at this point probably for Qt6), there in no much to do: an important feature like translations cannot be broken, as I pointed out on IRC, with my translator co-coordinator hat on.

As already said I interpret it as an absolute limit and will enforce it this way. Besides you're reiterating what I already said: An important feature like translations cannot be broken? As I said earlier: "functionality is more important to me." Either fix QML? Well, that's what this task is supposed to be about.

In T11721#201551, @ltoscano wrote:

This is not off-topic, because the limit you are trying to enforce is not an absolute limit, as stated in the same code that you are quoting. It's not about "code style can just go to shit". If the QML does not allow to have this, well, either fix QML (at this point probably for Qt6), there in no much to do: an important feature like translations cannot be broken, as I pointed out on IRC, with my translator co-coordinator hat on.

This is not off-topic, because the limit you are trying to enforce is not an absolute limit, as stated in the same code that you are quoting. It's not about "code style can just go to shit". If the QML does not allow to have this, well, either fix QML (at this point probably for Qt6), there in no much to do: an important feature like translations cannot be broken, as I pointed out on IRC, with my translator co-coordinator hat on.

In T11721#201544, @pino wrote:

[...]
So @romangg: please do not use non-absolute rules as absolute hammer to enforce poor localization, and think more about the users, thanks.

BTW, since the "100 characters per line" was brought as single argument, let's actually check what the KDE Frameworks Coding Style actually say.
Quoting bits from https://techbase.kde.org/Policies/Frameworks_Coding_Style (emphases mine):

If it helps, do all the experiments you want on kate-editor.org.
The web-server will re-pull the git all 5 minutes after some change.

Now I see that you mean, I added an import function. python3 translations.py extract directory/with/po/files

No, I think that's the structure required by sphinx. Make sure that import_po_dirs returns the structure that you need.
Please note that the use case of docs-krita-org involves multiple pot files. If you just need one (but again, it depends on the size), this is a simpler case:
https://cgit.kde.org/plasma-browser-integration.git/tree/StaticMessages.sh

Ok so I suppose the po files need to be located at locale/$lang/LC_MESSAGES, do I need to make a bash script instead?

Take a look at what krita does:

@ltoscano I created a merge request for translating the content of kate-editor.org https://invent.kde.org/websites/kate-editor-org/merge_requests/6

• if releaseme can fetch translations from SVN when creating the tarballs, I don't see how to do it
• size: it depends on how big the files are going to be
• not much; something is here: https://techbase.kde.org/Localization/Concepts/Auto_Assists#Daily_jobs_done_by_Scripty - but you don't need to know it, as long as you provide a script for extracting/merging, see what docs-krita-org does.

In T11721#201435, @ltoscano wrote:

Wasn't this solution mentioned here https://phabricator.kde.org/D23783#527600 ?

You mean like the following?

i18n(Lorem ipsum dolor sit amet, consectetur adipisici elit,\
     sed eiusmod tempor incidunt ut labore et dolore magna aliqua.)

True, the only difference is that the solution mentioned in D23783#527600 can not have an arbitrary indent. I'm not an expert on JavaScript string concatenation capabilities, but it would be nice to have multi-line strings not break the indent of code before and after.

In D13219#525698, @aacid wrote:

Should this be cancelled given this should be fixed on the latest ki18n?

Should this be cancelled given this should be fixed on the latest ki18n?

In D13219#500863, @safaalfulaij wrote:

In D13219#499990, @huftis wrote:>

I’ve just tested this, but changing %1 to %L1 doesn’t seem work; the %L1 is displayed verbatim.

Did you test it with Qt's system, or KI18n? I meant to use it with tr() (KF5 Tier 1 libraries that uses Qt localization system, like KI18n).

How does this ‘fix’ https://bugs.kde.org/show_bug.cgi?id=198872?

In D13219#499990, @huftis wrote:>

I’ve just tested this, but changing %1 to %L1 doesn’t seem work; the %L1 is displayed verbatim.