Difference between revisions of "Website Maintenance"

From GnuCash
Jump to: navigation, search
(Favicon: (new))
m (Favicon: typo)
Line 114: Line 114:
  
 
===Favicon===
 
===Favicon===
Because there are in between many flavours of favicons (resolutions, devices, OSes, browsers)you can use a service like  
+
Because there are in between many flavours of favicons (resolutions, devices, OSes, browsers) you can use a service like  
 
:[https://realfavicongenerator.net/ Favicon Generator. For real.]
 
:[https://realfavicongenerator.net/ Favicon Generator. For real.]
 
to check and update them.
 
to check and update them.

Revision as of 19:33, 15 August 2020

Sometimes something should be improved on our website. This page is intended to collect the right procedure.

Introduction

www.gnucash.org is the webserver of the GnuCash project. The sources are public available at GitHub. Building is done by a simple GNU Make.

Branches
Master: https://www.gnucash.org, the official site,
Beta: https://www.gnucash.org/beta/ is intended for developing major changes.

Content State

{sizing|develdocs}.phtml are currently (2017) hopeless outdated.

Used Standards

  • The static structure is usually written in HTML.
Html version & encoding
The main page is based on XHTML+RDFa with charset=UTF-8.
Todo
  • older parts are still HTML 4.01 and have charset=iso-8859-1.
  • A few, currently disabled, Social Media snippets would expect HTML 5.

Adding or Changing Text

If you add or change text, keep in mind Gnucash and its website are multilingual. If you - like me and most other people - are not firm in all languages, you should ask the translators, to help you keeping the translations up to date.

"Coding" Style

The current code is suboptimal. In the future follow standards:

HTML
(https://selfhtml.org/ is a good starting point in German)
PHP
The PHP Framework Interop Group published them. PSR-0 got obsoleted by PSR-4, so start with PSR-1: Basic Coding Standard.
  • Multiple occurrences of the same text: Assign it once to a variable and use that.

Metatags

Currently 2 sets of metatags are important/partly implemented:

  1. By Google recognized <meta> tags
  2. The Open Graph protocol is primary used by Facebook and requires at least the W3C standard Resource Description Framework in Attributes (RDFa).
Rules
If applicable,
  1. put content in a (PHP) $variable or $CONSTANT and use that in both flavours,
  2. mark it as _("Translatable").
Restrictions
Title
60 char,
Description
105 char, first words are today taken as keywords by Google,
Image
[TBD: currently slightly too big or because some of
type, width, length, alt
are missing]
Keyword
Negative impact today as they often were misused.

I18N

  • Translatable text is quoted:
 <?php echo T_("A translatable string");?>
  • Separate data (Numbers, URL, ...) from text:
Bad
 <?php echo T_("<span class=\"gnucash\">GnuCash</span> handles internationalized dates and currencies. The application's menus and popups have been translated to 21 languages, including Chinese, Danish, French, German, Hungarian, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Spanish, Swedish, Turkish, Ukrainian, and British English. Documentation is available in English, French, Portuguese and Spanish.");?></p>
Better
 <?php printf (T_("<span class=\"gnucash\">GnuCash</span> handles internationalized dates and currencies. The application's menus and popups have been translated to %u languages, including Chinese, Danish, French, German, Hungarian, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Spanish, Swedish, Turkish, Ukrainian, and British English. Documentation is available in English, French, Portuguese and Spanish."), 21);?></p>
Now an additional translation of the program will not break all website translations.
  • Try to avoid putting URLs in translatable strings, but
  • links to the wiki should be separate marked translatatable - there might be a translated page in the wiki.
  • addresses of images, which contain text should be translatable to link them to localized versions.
  • Todo: Try also to avoid Markups in the translatable text.
Fix me
Which methods should we use for the images? This needs documentation in Translation, too.

Managing Translations

After changing the english text, you should prepare the translation by

  1. creating a new .pot file
    make pot
  2. msgmerge all existing .po files
    make msgmerge
    and commit the updates
  3. send a short mail to gnucash-devel about "Translators: Website changed ..."
    feel free to give them some clues, what changed like
    "complete new download page" or
    "fixed 42 typos in the english text".
  4. As patches with reworked .po files arrive,
    1. If a language is new, add it in
      makefile
      to languages
    2. If a language is new or bitrotten, add or enable in
      externals/header.phtml
      a line in
      <span id="language">
      
      Note
      A few languages are disabled here, because they are bitrotten.
    3. apply them and
    4. make the .mo files, e.g. with
      make mos
    5. commit
      [[makefile, ]
      externals/header.phtml, ]
      po/LL.po and
      locale/LL/LC_MESSAGES/gnucash-htdocs.mo
      where LL is the language code.

Further details can be found on the Translation page.

Images

Icons should have a size of 32x32. We have a few tips in Documentation_Update_Instructions#Screenshots_and_Images.

Testing

make check

After modifying PHP parts, run
make check
before committing. This currently calls
php -l <file>
— PHP's integrated lint — for all php or phtml files.

W3C

  1. After pushing your commit press the W3C-Check button in the lower left corner of the website and fix any claimed errors.
    Do it for every page, which might by affected by your change. E.g. Changing a modules in /external might affect all pages.
  2. Do the same with CSS-Validator.
Note
W3C-check is the online version of the formatter and linter tidy. So in theory you can run the checks also locally before pushing by e.g.:
clear; LANGUAGE=C php index.phtml | tidy -config tidy.conf
to test the english version. It is possible, that a page is broken only in one language, if the translator made a mistake with the markups in the msgstrings like using uppercase tags, which are not allowed in XHTML.
To create an adjusted tidy.conf you can use
tidy -export-config >tidy.conf
and then adjust it. Enabling indentation and wrapping improves the readability.

Mobile Friendliness

Today there are more mobiles than desktop devices.

Metatags

If you changed Metatags and related elements like images, enter the URL at https://metatags.io/ to see how the page would appear in several social media.

Favicon

Because there are in between many flavours of favicons (resolutions, devices, OSes, browsers) you can use a service like

Favicon Generator. For real.

to check and update them.

On Your Localhost

Todo
Idea
Set up a web server, usually apache.
Tip
Eclipses PHP module can also run a test instance.
Add your repository to your apache configuration /etc/apache2/conf.d/
View http://localhost/gnucash/